From linfeng.john.zheng@gmail.com  Thu Mar  1 19:29:09 2012
Return-Path: <linfeng.john.zheng@gmail.com>
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 49EEF21E8078 for <behave@ietfa.amsl.com>; Thu,  1 Mar 2012 19:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.256
X-Spam-Level: ****
X-Spam-Status: No, score=4.256 tagged_above=-999 required=5 tests=[BAYES_60=1,  CN_BODY_16=0.013, CN_BODY_24=0.034, CN_BODY_832=0.004, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmTHx+QwRxNu for <behave@ietfa.amsl.com>; Thu,  1 Mar 2012 19:29:08 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C63BB21E8014 for <behave@ietf.org>; Thu,  1 Mar 2012 19:29:08 -0800 (PST)
Received: by iazz13 with SMTP id z13so1995156iaz.31 for <behave@ietf.org>; Thu, 01 Mar 2012 19:29:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zuOGRAie4PfMQePQOiB3XD0k7SeMkZO792ODzEkRm7w=; b=SGu/e6lcNOhP+b4A/a/8/oy5H5JrfS9wQsh1B2/9YokUwFBEqwjpkimzKxq2XV/GyZ jUntB5bVMHJOcbu2OmxyT/5DJ2QlkcJU7po1wAFy+2kTHrzzumWzEcYWzS8sLW4XOR4y XinZt9uAbGaaz5xMLt1oOK1XXXR6BWdND8YWHvjKGEkwlDsirk+JNTYPodmQFkLjkRDE Naks4EhsICC3Y92TW92x9lDZIcyIlin0mMxtzyXNFYvuhI8VXDL5qMeQDrZOZ/LBz4YP GboaeNa0sMU3EChWGKDRkr5gaSDAvrQcPGxm+JKs7mPoKLOO6x/i1ktLiCKLWbPTC9B5 WTlg==
MIME-Version: 1.0
Received: by 10.50.140.2 with SMTP id rc2mr326452igb.22.1330658948420; Thu, 01 Mar 2012 19:29:08 -0800 (PST)
Received: by 10.231.14.133 with HTTP; Thu, 1 Mar 2012 19:29:08 -0800 (PST)
Date: Fri, 2 Mar 2012 11:29:08 +0800
Message-ID: <CAG==GCAbAPzCUcgx+iJ0Gg0OOXi7=ofpiRN0HaBhYCEUxpAj3Q@mail.gmail.com>
From: Linfeng Zheng <linfeng.john.zheng@gmail.com>
To: behave@ietf.org
Content-Type: multipart/alternative; boundary=e89a8f50248af013cb04ba3a2d0d
Cc: behave-chairs@tools.ietf.org
Subject: [BEHAVE] Any update on next interim?
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 03:29:09 -0000

--e89a8f50248af013cb04ba3a2d0d
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: base64

RGVhciBhbGwsCgoKVGhhbmtzIERhdmUgZm9yIHRoZSAwMi8xNiBtaW51dGUuIEFueSBwbGFuIGZv
ciBvdXIgV0cgbWVldGluZz8gUGFyaXM/CgotLSAK0LvQu6Os1qPB1rflIEpvaG4gTGluZmVuZyBa
aGVuZwoKKszstdiyyruqKs7Eu6/Qxc+i18nRr9PQz97U8MjOuavLviBDSEEgQ29uc3VsdGluZyBG
aXJtCta00NC2rcrCL76twO0gUHJlc2lkZW50L0NFTwoKtee7sChUZWwpOiArODYtNTkxLTgzODA5
MDMxKE8pICAxNTMwNjkxNTU0OChDZWxsKSAxNTE5NTc2MjA2NSjE/k5KKQq12Na3KEFkZHIpOiC4
o9bdytC4o9DCwrcyMzm6xcur19PQx7Tzz8PI/cKlo8LH+DgxMKOsUC5SLkNoaW5hCrKpv80oQmxv
Zyk6IGh0dHA6Ly9ibG9nLnNpbmEuY29tLmNuLzIzZ3RyZWVzCg==
--e89a8f50248af013cb04ba3a2d0d
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div>Dear all,</div><div>&nbsp;</div><div><br clear=3D"all">Thanks Dave for=
 the 02/16 minute. Any plan for our WG meeting? Paris?</div><div><br>-- <br=
></div><div><span style=3D"color:rgb(0,0,0);text-transform:none;line-height=
:normal;text-indent:0px;letter-spacing:normal;font-family:Simsun;font-style=
:normal;font-variant:normal;font-weight:normal;word-spacing:0px;white-space=
:normal;border-collapse:separate"><span style=3D"font-family:arial">=D0=BB=
=D0=BB=A3=AC=D6=A3=C1=D6=B7=E5</span></span> John Linfeng Zheng&nbsp;</div>


<div>&nbsp;</div>
<div><strong><font size=3D"4"><font color=3D"#33ccff">=CC=EC</font><font co=
lor=3D"#009900">=B5=D8</font><font color=3D"#3333ff">=B2=CA</font><font col=
or=3D"#ff0000">=BB=AA</font></font></strong>=CE=C4=BB=AF=D0=C5=CF=A2=D7=C9=
=D1=AF=D3=D0=CF=DE=D4=F0=C8=CE=B9=AB=CB=BE CHA Consulting Firm</div>
<div>=D6=B4=D0=D0=B6=AD=CA=C2/=BE=AD=C0=ED President/CEO</div>
<div>&nbsp;</div>
<div>=B5=E7=BB=B0(Tel): +86-591-83809031(O)&nbsp; 15306915548(Cell) 1519576=
2065(=C4=FENJ) </div>
<div>=B5=D8=D6=B7(Addr): =B8=A3=D6=DD=CA=D0=B8=A3=D0=C2=C2=B7239=BA=C5=CB=
=AB=D7=D3=D0=C7=B4=F3=CF=C3=C8=FD=C2=A5=A3=C2=C7=F8810=A3=ACP.R.China</div>
<div><span style=3D"color:rgb(0,0,0);text-transform:none;line-height:normal=
;text-indent:0px;letter-spacing:normal;font-family:Simsun;font-style:normal=
;font-variant:normal;font-weight:normal;word-spacing:0px;white-space:normal=
;border-collapse:separate"><span style=3D"color:rgb(136,136,136);font-famil=
y:arial,sans-serif;border-collapse:collapse"><font color=3D"#000000">=B2=A9=
=BF=CD(Blog):</font><span>&nbsp;</span><a style=3D"color:rgb(7,77,143)" hre=
f=3D"http://blog.sina.com.cn/23gtrees" target=3D"_blank">http://blog.sina.c=
om.cn/23gtrees</a></span></span></div>

<br>

--e89a8f50248af013cb04ba3a2d0d--

From internet-drafts@ietf.org  Fri Mar  2 00:59:46 2012
Return-Path: <internet-drafts@ietf.org>
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 A887821F871C; Fri,  2 Mar 2012 00:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byyk+6I0os+L; Fri,  2 Mar 2012 00:59:46 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC3621F86F2; Fri,  2 Mar 2012 00:59:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120302085943.9099.91393.idtracker@ietfa.amsl.com>
Date: Fri, 02 Mar 2012 00:59:43 -0800
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-64-analysis-07.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 08:59:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Behavior Engineering for Hindrance Av=
oidance Working Group of the IETF.

	Title           : Analysis of Stateful 64 Translation
	Author(s)       : Reinaldo Penno
                          Tarun Saxena
                          Mohamed Boucadair
                          Senthil Sivakumar
	Filename        : draft-ietf-behave-64-analysis-07.txt
	Pages           : 15
	Date            : 2012-03-02

   Due to specific problems, NAT-PT was deprecated by the IETF as a
   mechanism to perform IPv6-IPv4 translation.  Since then, new efforts
   have been undertaken within IETF to standardize alternative
   mechanisms to perform IPv6-IPv4 translation.  This document analyzes
   to what extent the new stateful translation mechanisms avoid the
   problems that caused the IETF to deprecate NAT-PT.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-64-analysis-07.txt


From etienne.duble@imag.fr  Fri Mar  2 09:10:38 2012
Return-Path: <etienne.duble@imag.fr>
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 718F721F859F for <behave@ietfa.amsl.com>; Fri,  2 Mar 2012 09:10:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2PLYIH04Po9 for <behave@ietfa.amsl.com>; Fri,  2 Mar 2012 09:10:30 -0800 (PST)
Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3321F84BD for <behave@ietf.org>; Fri,  2 Mar 2012 09:10:29 -0800 (PST)
Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id q22H6VRZ008313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 18:06:31 +0100
Received: from taiwan.imag.fr (taiwan.imag.fr [129.88.49.126]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id q22HBfD3019956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 18:11:42 +0100
Message-ID: <4F50FEFF.30508@imag.fr>
Date: Fri, 02 Mar 2012 18:10:23 +0100
From: =?ISO-8859-1?Q?Etienne_Dubl=E9?= <etienne.duble@imag.fr>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: behave@ietf.org
References: <20120229185846.1558D72E08A@rfc-editor.org>
In-Reply-To: <20120229185846.1558D72E08A@rfc-editor.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Fri, 02 Mar 2012 18:06:31 +0100 (CET)
X-IMAG-MailScanner-Information: Please contact MI2S MIM  for more information
X-MailScanner-ID: q22H6VRZ008313
X-IMAG-MailScanner: Found to be clean
X-IMAG-MailScanner-SpamCheck: 
X-IMAG-MailScanner-From: etienne.duble@imag.fr
MailScanner-NULL-Check: 1331312794.83729@ExOupJplT7j8/oHBr9WAfA
Cc: Andrzej Duda <Andrzej.duda@imag.fr>, Franck Rousseau <Franck.Rousseau@imag.fr>
Subject: Re: [BEHAVE] RFC 6535 on Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 17:10:38 -0000

Le 29/02/2012 19:58, rfc-editor@rfc-editor.org a écrit :
> A new Request for Comments is now available in online RFC libraries.
>
>
>          RFC 6535
>
>          Title:      Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
>

Hello,
And thanks for this very interesting document.
I just noticed the following: it seems the RFC numbers are swapped in 
the following sentence (part 7.)

"
This document recommends the socket API-layer implementation
option over network layer translation, i.e., it recommends the
approach introduced in RFC 2767 over the approach of RFC 3338.
"

I would also like to point you to the following tool: 
http://sourceforge.net/projects/ipv6-care/. It uses an approach very 
similar to the RFC, with some additional features (and also things that 
should be improved with respect to the RFC). For example it can also 
handle servers.
At https://twiki.cern.ch/twiki/bin/view/EGEE/IPv6CARE you can view a 
video where mysql client and server are talking over IPv6, although none 
of them are IPv6-compliant.
I am the main developper of this tool. IPv6 CARE stands for IPv6 
Compliant Automatic Runtime Environment, it's free and open source 
(Apache license). It uses the API translation mechanism (LD_PRELOAD on 
UNIX).

FYI, I listed below the differences I noticed between the behavior of 
IPv6 CARE and the behavior described in the RFC.
If you have comments about it I would be happy to read them.
Regards
Etienne Duble

--------------

Differences IPv6 CARE / RFC:
- IPv6 CARE also addresses the case of servers (TCP, for now) i.e. when 
patching a server it ensures (at accept() time) that both IPv4 and IPv6 
clients can connect: when needed it opens an additional IPv6 socket and 
performs a select().
- For clients, the mechanism in IPv6 CARE is sometimes triggered at 
connection time, not only at name resolution time. For example if the 
client tries to connect to a dual-stack server (A and AAAA records 
available), the A record will be tried first, and if the connect() call 
fails, then the tool will also try to connect using the IPv6 address of 
the server. Since this is triggered by the connection failure, all this 
is implemented during the connect() phase.
- IPv6 CARE is more complicated. For example in the previous case the 
connect() call is replaced by a specialized algorithm, and therefore the 
trivial 'function mapper' described in the RFC cannot be applied.
- IPv6 CARE also addresses the conversion of addresses (i.e. when a 
synthetic IPv4 address is involved), from binary to text and from text 
to binary (modification of inet_ntoa, inet_aton, inet_ntop, ...)
- The 'Special Exclusion Sets' are not implemented (yet). For now the 
pool is configured at installation time with a subnet of RFC1918 addresses.
- IPv6 CARE does not handle ICMP (i.e. it keep it untouched).
- Security aspects in IPv6 CARE should be improved.


-- 
Etienne Dublé
CNRS / LIG - Drakkar and Hadas teams
+33 (0)476827276



From dwing@cisco.com  Fri Mar  2 10:49:43 2012
Return-Path: <dwing@cisco.com>
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 AE5B821E8057 for <behave@ietfa.amsl.com>; Fri,  2 Mar 2012 10:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.361
X-Spam-Level: 
X-Spam-Status: No, score=-106.361 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_50=0.001, CN_BODY_16=0.013, CN_BODY_24=0.034,  CN_BODY_832=0.004, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOt1dEqQ588e for <behave@ietfa.amsl.com>; Fri,  2 Mar 2012 10:49:43 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EC4F621E8054 for <behave@ietf.org>; Fri,  2 Mar 2012 10:49:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1939; q=dns/txt; s=iport; t=1330714182; x=1331923782; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=nSQwDRd3tIrRR8AsA2rhyMORLwtBvn3u4vq58l/nhTM=; b=ABKlq9SOrY317txpd+rf+f0297lXxsCFlSl/src7ttsaAjEAkoLAjDgl AOkfnJLsIPpGwMNc3G78cAHmhou0tNyIweDTyIJDnejfRciYceU9prWM3 lqQo7PKTJcws17oB+hUQ7gp0XTe4KXKxiMTRz9IPFfxsUjKSPtH8y/8CK M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFALYVUU+rRDoG/2dsb2JhbABDhT+fIY9mgQeBfQEBAQQICgEXPgYLDAEDAgcCDwIEAQEFIwUCGSMKCQgBAQQBEgkCF4djDKEKAYxfCIo6gSuNH4EaBIhQhQqTBYd1gTME
X-IronPort-AV: E=Sophos;i="4.73,519,1325462400"; d="scan'208";a="31634963"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 02 Mar 2012 18:49:42 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q22Ingu5018844; Fri, 2 Mar 2012 18:49:42 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Linfeng Zheng'" <linfeng.john.zheng@gmail.com>, <behave@ietf.org>
References: <CAG==GCAbAPzCUcgx+iJ0Gg0OOXi7=ofpiRN0HaBhYCEUxpAj3Q@mail.gmail.com>
In-Reply-To: <CAG==GCAbAPzCUcgx+iJ0Gg0OOXi7=ofpiRN0HaBhYCEUxpAj3Q@mail.gmail.com>
Date: Fri, 2 Mar 2012 10:49:42 -0800
Message-ID: <048901ccf8a5$3ad14fb0$b073ef10$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acz4JKPy0eml+2bBSESJyw1AjB0XUAAf0BiQ
Content-Language: en-us
Cc: behave-chairs@tools.ietf.org
Subject: Re: [BEHAVE] Any update on next interim?
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 18:49:43 -0000

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Linfeng Zheng
> Sent: Thursday, March 01, 2012 7:29 PM
> To: behave@ietf.org
> Cc: behave-chairs@tools.ietf.org
> Subject: [BEHAVE] Any update on next interim?
>=20
> Dear all,
>=20
>=20
> Thanks Dave for the 02/16 minute. Any plan for our WG meeting? Paris?

We had an interim meeting today (March 2).  This was announced on the =
BEHAVE
mailing list and by the IESG Secretary.

We will _not_ have a face-to-face meeting in Paris.  We cancelled that
meeting because the Transport area had too many conflicts and chairs =
were
encouraged to drop sessions if possible.  Based on our February 16 =
interim
conference call, the chairs felt we could cancel the face-to-face =
meeting in
Paris without significantly harming forward progress on the working =
group's
milestones.

Our next conference call interim meeting is tentatively scheduled for
Thursday, April 19, 7am Pacific Time.  This is three weeks after the =
IETF in
Paris.  We will be finalizing that date/time and make an official
announcement during the IETF week. =20

The guidance for conference call interim meetings is published at
http://www.ietf.org/iesg/statement/interim-meetings.html, and requires a =
two
week notice prior to conference call interim meetings.

-d


> --
>=20
> =D0=BB=D0=BB=A3=AC=D6=A3=C1=D6=B7=E5 John Linfeng Zheng
>=20
> =
=CC=EC=B5=D8=B2=CA=BB=AA=CE=C4=BB=AF=D0=C5=CF=A2=D7=C9=D1=AF=D3=D0=CF=DE=D4=
=F0=C8=CE=B9=AB=CB=BE CHA Consulting Firm
> =D6=B4=D0=D0=B6=AD=CA=C2/=BE=AD=C0=ED President/CEO
>=20
> =B5=E7=BB=B0(Tel): +86-591-83809031(O)  15306915548(Cell) =
15195762065(=C4=FENJ)
> =B5=D8=D6=B7(Addr): =
=B8=A3=D6=DD=CA=D0=B8=A3=D0=C2=C2=B7239=BA=C5=CB=AB=D7=D3=D0=C7=B4=F3=CF=C3=
=C8=FD=C2=A5=A3=C2=C7=F8810=A3=ACP.R.China
> =B2=A9=BF=CD(Blog): http://blog.sina.com.cn/23gtrees



From mperumal@cisco.com  Sun Mar  4 13:27:22 2012
Return-Path: <mperumal@cisco.com>
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 BADD421F85E7 for <behave@ietfa.amsl.com>; Sun,  4 Mar 2012 13:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.952
X-Spam-Level: 
X-Spam-Status: No, score=-8.952 tagged_above=-999 required=5 tests=[AWL=1.647,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zli52pwrn6Ey for <behave@ietfa.amsl.com>; Sun,  4 Mar 2012 13:27:22 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87021F858E for <behave@ietf.org>; Sun,  4 Mar 2012 13:27:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=1956; q=dns/txt; s=iport; t=1330896441; x=1332106041; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=o1oy/WXiRe7Kj/+4JLBhzoHqoFC05+E0Ia3Wh2nU/1g=; b=dB8EObUY4KolQ7QB14hSdK/qadGOQgyQnSdowlOvPOmf33ucVkJeCy1p L2KDOoD0UtCvHYaOfh4mP7H9cjVhz0gIFu4wkCmC8vNU6uHD1qamSKJVv NeAWdkXaG4K4KyCF/K0K+zkaE/suwAjybm3R5SDtm1z/nJg7s4R3lmi4/ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EABrdU09Io8UY/2dsb2JhbABDtUmBfQEBAQQBAQEPAR0KNBcGAQgRBAEBCwYNCgEHJh8HAQEFBAEECwgIARmHZQuYTYEnAZ17jTuCP2MEiE6YEIRygms
X-IronPort-AV: E=Sophos;i="4.73,530,1325462400";  d="scan'208";a="7071928"
Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 04 Mar 2012 21:27:20 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q24LRJ0r005058 for <behave@ietf.org>; Sun, 4 Mar 2012 21:27:19 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 5 Mar 2012 02:57:19 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Mar 2012 02:57:16 +0530
Message-ID: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action: draft-muthu-behave-consent-freshness-00.txt
Thread-Index: Acz6R35Ou7QXi4NgRu2c98nsE863sQABWp+Q
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: <behave@ietf.org>
X-OriginalArrivalTime: 04 Mar 2012 21:27:19.0668 (UTC) FILETIME=[946FC340:01CCFA4D]
Subject: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Mar 2012 21:27:22 -0000

This I-D describes a new STUN usage for enabling WebRTC implementations
to perform consent freshness. It is far from complete, but comments
(especially on the design considerations/approach) are welcome..

Muthu

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Monday, March 05, 2012 2:14 AM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-muthu-behave-consent-freshness-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : STUN Usage for Consent Freshness
	Author(s)       : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Hadriel Kaplan
	Filename        : draft-muthu-behave-consent-freshness-00.txt
	Pages           : 10
	Date            : 2012-03-04

   This document describes a STUN usage that enables WebRTC
   implementations to verify the peer consent for continuing to receive
   traffic on a candidate pair ICE is using for a media component after
   session establishment.  Verification of peer consent is necessary to
   ensure that a malicious JavaScript cannot use the browser as a
   platform for launching attacks.  This form of consent verification
   also serves the purpose of refreshing NAT bindings.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness
-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-muthu-behave-consent-freshness-
00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From simon.perreault@viagenie.ca  Mon Mar  5 07:02:54 2012
Return-Path: <simon.perreault@viagenie.ca>
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 2979421F8781 for <behave@ietfa.amsl.com>; Mon,  5 Mar 2012 07:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level: 
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqvN45AsGCNw for <behave@ietfa.amsl.com>; Mon,  5 Mar 2012 07:02:53 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 003D621F8780 for <behave@ietf.org>; Mon,  5 Mar 2012 07:02:52 -0800 (PST)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8c46:de1b:764:c20]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 66C7220E7B; Mon,  5 Mar 2012 10:02:52 -0500 (EST)
Message-ID: <4F54D59B.9020104@viagenie.ca>
Date: Mon, 05 Mar 2012 10:02:51 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com>
In-Reply-To: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 15:02:54 -0000

On 2012-03-04 16:27, Muthu Arul Mozhi Perumal (mperumal) wrote:
> This I-D describes a new STUN usage for enabling WebRTC implementations
> to perform consent freshness. It is far from complete, but comments
> (especially on the design considerations/approach) are welcome..

I had a *very* quick look at it, and have a few questions. They're 
mostly "explain it to me like a two year old" type questions, so maybe 
the answers could be added to the doc itself.

- Looking at section "6. STUN Consent Method Processing", I don't see 
any difference between a Binding request and a Consent request on the 
server side. So how could a Consent request have different semantics 
than a Binding request if they are processed identically by the server?

- Why a new method instead of a new attribute? A new attribute 
indicating additional semantics seems more appropriate to me because all 
Binding processing would automatically be inherited by Consent. E.g. in 
the future we define a new Binding attribute, chances are it would also 
apply to Consent. All you need is a way to indicate "this is a regular 
Binding request but *additionally* I'm asking if you consent to me 
sending you packets". The server would include the consent attribute in 
the response if it consents, otherwise, and if it doesn't support that 
attribute, it would just ignore it and reply like a normal Binding 
request, which would be useful. Also you would inherit a lot of text 
about the mechanics (e.g. sections 6.1-6.4 marked TBD would be unnecessary).

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 iesg-secretary@ietf.org  Tue Mar  6 09:10:58 2012
Return-Path: <iesg-secretary@ietf.org>
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 4EDE821E80A9; Tue,  6 Mar 2012 09:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level: 
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfX-QUmyIv-K; Tue,  6 Mar 2012 09:10:57 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CEC21E80AC; Tue,  6 Mar 2012 09:10:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120306171057.18860.46266.idtracker@ietfa.amsl.com>
Date: Tue, 06 Mar 2012 09:10:57 -0800
Cc: behave mailing list <behave@ietf.org>, behave chair <behave-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [BEHAVE] Document Action: 'Analysis of Stateful 64 Translation' to	Informational RFC (draft-ietf-behave-64-analysis-07.txt)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 17:10:58 -0000

The IESG has approved the following document:
- 'Analysis of Stateful 64 Translation'
  (draft-ietf-behave-64-analysis-07.txt) as an Informational RFC

This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.

The IESG contact persons are David Harrington and Wesley Eddy.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-behave-64-analysis/




Technical Summary

Due to specific problems, NAT-PT was deprecated by the IETF as a
mechanism to perform IPv6-IPv4 translation. Since then, new efforts
have been undertaken within IETF to standardize alternative
mechanisms to perform IPv6-IPv4 translation. This document evaluates
how the new stateful translation mechanisms avoid the problems that
caused the IETF to deprecate NAT-PT.

Working Group Summary

Nothing exciting happened.

Document Quality

This is not a protocol,  but an analysis document.
Therefore there are no implementations or promises to implement.

Personnel

shepherd: Dan Wing
responsible AD: David Harrington

RFC Editor Note

  please move pcp-base to the normative reference section.

From mperumal@cisco.com  Tue Mar  6 10:08:55 2012
Return-Path: <mperumal@cisco.com>
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 E6DCC21F858B for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 10:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.158
X-Spam-Level: 
X-Spam-Status: No, score=-9.158 tagged_above=-999 required=5 tests=[AWL=1.441,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnySV4uAUgvl for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 10:08:54 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 30CE421F8523 for <behave@ietf.org>; Tue,  6 Mar 2012 10:08:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4255; q=dns/txt; s=iport; t=1331057333; x=1332266933; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4Hv0L1o9i60J+m+0Q7V74rzVz4+QvaT1MH2S0TmSHc8=; b=PlaaJDyQ5Tm5wq5Dl53vCAcn2Ey0E8xaBKOX4H0DESEiHb3YX7Tu2DY9 XvI8fLnYWEs5WRRC0lBHRYiOgbF4Ts8ZQNdnFF1kMOVKXQsRQvxtdn+k2 MthzsgW6z08ImafdnFLDwsLLPqHiNhysP3dhwaw3DlwmB5OBjA9cp+qTw o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAChSVk9Io8UY/2dsb2JhbABDtgSBfQEBAQQSARQJCj8MBAIBCBEEAQELBhcBBgFFCAEIAQEECwgIGodloG8BlzOPe2MEiFCdBYJrgUwF
X-IronPort-AV: E=Sophos;i="4.73,540,1325462400";  d="scan'208";a="7232194"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 06 Mar 2012 18:08:51 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q26I8nNW023250; Tue, 6 Mar 2012 18:08:51 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Mar 2012 23:38:49 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 Mar 2012 23:36:35 +0530
Message-ID: <1D062974A4845E4D8A343C653804920207CF010F@XMB-BGL-414.cisco.com>
In-Reply-To: <4F54D59B.9020104@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt
Thread-Index: Acz64QxHabVchwxETfKCCn4lR2o3dQAzJskw
References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> <4F54D59B.9020104@viagenie.ca>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Simon Perreault" <simon.perreault@viagenie.ca>
X-OriginalArrivalTime: 06 Mar 2012 18:08:49.0692 (UTC) FILETIME=[2E5D25C0:01CCFBC4]
Cc: behave@ietf.org
Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 18:08:55 -0000

|- Looking at section "6. STUN Consent Method Processing",
|I don't see any difference between a Binding request and=20
|a Consent request on the server side. So how could a Consent=20
|request have different semantics than a Binding request if=20
|they are processed identically by the server?

To make sure I understand correctly, by a server you don't mean a STUN
server sitting in the Internet used for resolving the NAT'ed address,
right? Such a server isn't expected to receive a consent request.
Consent request/response is expected to be used b/w two endpoints
involved in a real-time communication session.

>From the server side, the main difference b/w the Binding request
processing and the Consent request processing is the message integrity
verification. While a Binding request in the ICE usage would require
verification of the message integrity using the short-term credential
mechanism, the consent request will not. A consent request is also not
expected to contain any other attribute except FINGERPRINT (and probably
SOFTWARE). So, once the server identifies it as a consent request based
on the message type fields in the STUN header, it would branch out of
Binding request processing and process the request as a consent request.

I agree this isn't clearly described in section 6 and it needs to be
updated.

|- Why a new method instead of a new attribute?

As described in the design considerations section, the ICE usage
requires the message integrity and short-term credentials to be used
with Binding request/response. These are not needed for consent
freshness. One could add a new attribute to call out an ICE exception.
However, depending on where in the stack an implementation does the
integrity verification, an implementation may throw out a Binding
request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
attributes. In addition, a Binding request sent for consent freshness
can cause ICE reprocessing if an implementation doesn't handle it
properly.

I am not saying it can't be done using a new attribute. But, using a new
method looks cleaner and less troublesome with existing deployments.

Muthu

|-----Original Message-----
|From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
|Sent: Monday, March 05, 2012 8:33 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action:
draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-04 16:27, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> This I-D describes a new STUN usage for enabling WebRTC
implementations
|> to perform consent freshness. It is far from complete, but comments
|> (especially on the design considerations/approach) are welcome..
|
|I had a *very* quick look at it, and have a few questions. They're
|mostly "explain it to me like a two year old" type questions, so maybe
|the answers could be added to the doc itself.
|
|- Looking at section "6. STUN Consent Method Processing", I don't see
|any difference between a Binding request and a Consent request on the
|server side. So how could a Consent request have different semantics
|than a Binding request if they are processed identically by the server?
|
|- Why a new method instead of a new attribute? A new attribute
|indicating additional semantics seems more appropriate to me because
all
|Binding processing would automatically be inherited by Consent. E.g. in
|the future we define a new Binding attribute, chances are it would also
|apply to Consent. All you need is a way to indicate "this is a regular
|Binding request but *additionally* I'm asking if you consent to me
|sending you packets". The server would include the consent attribute in
|the response if it consents, otherwise, and if it doesn't support that
|attribute, it would just ignore it and reply like a normal Binding
|request, which would be useful. Also you would inherit a lot of text
|about the mechanics (e.g. sections 6.1-6.4 marked TBD would be
unnecessary).
|
|Simon
|--
|DTN made easy, lean, and smart --> http://postellation.viagenie.ca
|NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
|STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Tue Mar  6 10:49:40 2012
Return-Path: <simon.perreault@viagenie.ca>
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 EB9A721E80B3 for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 10:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncv-mTVeEot4 for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 10:49:40 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 04A6821E8096 for <behave@ietf.org>; Tue,  6 Mar 2012 10:49:40 -0800 (PST)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:a11b:9b29:9caf:fd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 213B021F15; Tue,  6 Mar 2012 13:49:39 -0500 (EST)
Message-ID: <4F565C42.3080503@viagenie.ca>
Date: Tue, 06 Mar 2012 13:49:38 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> <4F54D59B.9020104@viagenie.ca> <1D062974A4845E4D8A343C653804920207CF010F@XMB-BGL-414.cisco.com>
In-Reply-To: <1D062974A4845E4D8A343C653804920207CF010F@XMB-BGL-414.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 18:49:41 -0000

On 2012-03-06 13:06, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |- Looking at section "6. STUN Consent Method Processing",
> |I don't see any difference between a Binding request and
> |a Consent request on the server side. So how could a Consent
> |request have different semantics than a Binding request if
> |they are processed identically by the server?
>
> To make sure I understand correctly, by a server you don't mean a STUN
> server sitting in the Internet used for resolving the NAT'ed address,
> right? Such a server isn't expected to receive a consent request.
> Consent request/response is expected to be used b/w two endpoints
> involved in a real-time communication session.

Right. By "server" I mean the peer that receives the STUN request.

> From the server side, the main difference b/w the Binding request
> processing and the Consent request processing is the message integrity
> verification. While a Binding request in the ICE usage would require
> verification of the message integrity using the short-term credential
> mechanism, the consent request will not. A consent request is also not
> expected to contain any other attribute except FINGERPRINT (and probably
> SOFTWARE). So, once the server identifies it as a consent request based
> on the message type fields in the STUN header, it would branch out of
> Binding request processing and process the request as a consent request.

What does "process the request as a consent request" mean? From the 
draft it looks like it could mean exactly the same as for a Binding 
request...

In other words, what's the difference between a consent request and a 
keepalive?

> |- Why a new method instead of a new attribute?
>
> As described in the design considerations section, the ICE usage
> requires the message integrity and short-term credentials to be used
> with Binding request/response. These are not needed for consent
> freshness. One could add a new attribute to call out an ICE exception.

I'm not following you. ICE requires short-term auth for *connectivity 
checks*. Those are done *before* ICE concludes. ICE does not require 
short-term auth for Binding requests sent *after* ICE concludes. For 
keepalives, it even says that auth must not be used.

> However, depending on where in the stack an implementation does the
> integrity verification, an implementation may throw out a Binding
> request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
> attributes. In addition, a Binding request sent for consent freshness
> can cause ICE reprocessing if an implementation doesn't handle it
> properly.

That argument can be used to justify anything. I could say that your new 
Consent request could be interpreted as a Crash-Right-Now message if an 
implementation doesn't handle it properly.

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 mperumal@cisco.com  Tue Mar  6 11:23:52 2012
Return-Path: <mperumal@cisco.com>
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 33ED321E80AE for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 11:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.318
X-Spam-Level: 
X-Spam-Status: No, score=-9.318 tagged_above=-999 required=5 tests=[AWL=1.281,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qolQtiWPH55T for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 11:23:50 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1D37E21E8087 for <behave@ietf.org>; Tue,  6 Mar 2012 11:23:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5247; q=dns/txt; s=iport; t=1331061829; x=1332271429; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nzMkdzvIjBCAYA6qyNYuTpiPy5X77XsBXhCy+agnlsk=; b=CtvTLMvZHip6VJ8CBH2qvpRL/v+l4jXpBhP6uDMqQoR704ntneRa5Pmu 1XccI05JQSNQI7QjDzSCSixqEHhdRm8lagUHA5ltX6bcKdylp7ldmj8wI j4uXLHkC822hS5QpidEQU59tCa2E7mxGfE7vbPuVfyufh8+MbRtsBgrn0 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAPtjVk9Io8UY/2dsb2JhbABDtXiBfQEBAQQBAQEPARQJCjQLDAQCAQgRBAEBCwYXAQYBJh8IAQgBAQQLCAgah2ULmjwBnx2KJoVVYwSIUJ0FgmuBTAEE
X-IronPort-AV: E=Sophos;i="4.73,541,1325462400";  d="scan'208";a="7230961"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 06 Mar 2012 19:23:47 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q26JNkhl019096; Tue, 6 Mar 2012 19:23:47 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Mar 2012 00:53:46 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Mar 2012 00:53:44 +0530
Message-ID: <1D062974A4845E4D8A343C653804920207CF0123@XMB-BGL-414.cisco.com>
In-Reply-To: <4F565C42.3080503@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [BEHAVE] FW: I-D Action:draft-muthu-behave-consent-freshness-00.txt
Thread-Index: Acz7yeiLBl/sxq5gQZCe7sSVuKlpfgAAGPig
References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com><4F54D59B.9020104@viagenie.ca><1D062974A4845E4D8A343C653804920207CF010F@XMB-BGL-414.cisco.com> <4F565C42.3080503@viagenie.ca>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Simon Perreault" <simon.perreault@viagenie.ca>
X-OriginalArrivalTime: 06 Mar 2012 19:23:46.0734 (UTC) FILETIME=[A6CF4CE0:01CCFBCE]
Cc: behave@ietf.org
Subject: Re: [BEHAVE] FW: I-D Action:draft-muthu-behave-consent-freshness-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 19:23:52 -0000

|In other words, what's the difference between a consent request
|and a keepalive?

A keepalive is a Binding indication that does not evoke a response,
whereas a consent request does.

|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.

<snip from the RFC5245>
   B.4.  Importance of the STUN Username

   ICE requires the usage of message integrity with STUN using its
   short-term credential functionality.  The actual short-term
   credential is formed by exchanging username fragments in the SDP
   offer/answer exchange.

   B.10.  Why Are Binding Indications Used for Keepalives?

   Additionally, using a Binding Indication allows integrity to be
   disabled, allowing for better performance.  This is useful for large-
   scale endpoints, such as PSTN gateways and SBCs.
</snip>

It doesn't look ICE intended to limit the message integrity and
short-term auth for connectivity checks alone -- it looks applicable for
any Binding request/response transaction.

<snip from the RFC5245>
   10.  Keepalives
   Though Binding Indications are used for keepalives,
   an agent MUST be prepared to receive a connectivity check as well.
   If a connectivity check is received, a response is generated as
   discussed in [RFC5389], but there is no impact on ICE processing
   otherwise.
</snip>

If a connectivity check is received for keepalive, it should use the
message integrity and short-term auth, I think.

Muthu

|-----Original Message-----
|From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
Behalf Of Simon Perreault
|Sent: Wednesday, March 07, 2012 12:20 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D
Action:draft-muthu-behave-consent-freshness-00.txt
|
|On 2012-03-06 13:06, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |- Looking at section "6. STUN Consent Method Processing",
|> |I don't see any difference between a Binding request and
|> |a Consent request on the server side. So how could a Consent
|> |request have different semantics than a Binding request if
|> |they are processed identically by the server?
|>
|> To make sure I understand correctly, by a server you don't mean a
STUN
|> server sitting in the Internet used for resolving the NAT'ed address,
|> right? Such a server isn't expected to receive a consent request.
|> Consent request/response is expected to be used b/w two endpoints
|> involved in a real-time communication session.
|
|Right. By "server" I mean the peer that receives the STUN request.
|
|> From the server side, the main difference b/w the Binding request
|> processing and the Consent request processing is the message
integrity
|> verification. While a Binding request in the ICE usage would require
|> verification of the message integrity using the short-term credential
|> mechanism, the consent request will not. A consent request is also
not
|> expected to contain any other attribute except FINGERPRINT (and
probably
|> SOFTWARE). So, once the server identifies it as a consent request
based
|> on the message type fields in the STUN header, it would branch out of
|> Binding request processing and process the request as a consent
request.
|
|What does "process the request as a consent request" mean? From the
|draft it looks like it could mean exactly the same as for a Binding
|request...
|
|In other words, what's the difference between a consent request and a
|keepalive?
|
|> |- Why a new method instead of a new attribute?
|>
|> As described in the design considerations section, the ICE usage
|> requires the message integrity and short-term credentials to be used
|> with Binding request/response. These are not needed for consent
|> freshness. One could add a new attribute to call out an ICE
exception.
|
|I'm not following you. ICE requires short-term auth for *connectivity
|checks*. Those are done *before* ICE concludes. ICE does not require
|short-term auth for Binding requests sent *after* ICE concludes. For
|keepalives, it even says that auth must not be used.
|
|> However, depending on where in the stack an implementation does the
|> integrity verification, an implementation may throw out a Binding
|> request/response if it doesn't find the MESSAGE-INTEGRITY or USERNAME
|> attributes. In addition, a Binding request sent for consent freshness
|> can cause ICE reprocessing if an implementation doesn't handle it
|> properly.
|
|That argument can be used to justify anything. I could say that your
new
|Consent request could be interpreted as a Crash-Right-Now message if an
|implementation doesn't handle it properly.
|
|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
|_______________________________________________
|Behave mailing list
|Behave@ietf.org
|https://www.ietf.org/mailman/listinfo/behave

From simon.perreault@viagenie.ca  Tue Mar  6 12:07:44 2012
Return-Path: <simon.perreault@viagenie.ca>
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 4EE4921E80C8 for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 12:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level: 
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0disxWnm54w9 for <behave@ietfa.amsl.com>; Tue,  6 Mar 2012 12:07:43 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8711A21E80C4 for <behave@ietf.org>; Tue,  6 Mar 2012 12:07:43 -0800 (PST)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:a11b:9b29:9caf:fd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB18520E2E; Tue,  6 Mar 2012 15:07:42 -0500 (EST)
Message-ID: <4F566E8E.6040302@viagenie.ca>
Date: Tue, 06 Mar 2012 15:07:42 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com><4F54D59B.9020104@viagenie.ca><1D062974A4845E4D8A343C653804920207CF010F@XMB-BGL-414.cisco.com> <4F565C42.3080503@viagenie.ca> <1D062974A4845E4D8A343C653804920207CF0123@XMB-BGL-414.cisco.com>
In-Reply-To: <1D062974A4845E4D8A343C653804920207CF0123@XMB-BGL-414.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] FW: I-D Action:draft-muthu-behave-consent-freshness-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 20:07:44 -0000

On 2012-03-06 14:23, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |In other words, what's the difference between a consent request
> |and a keepalive?
>
> A keepalive is a Binding indication that does not evoke a response,
> whereas a consent request does.

Aaaaah! I think I'm starting to understand... You want a way to know if 
the peer is still listening to you! And you can't use a simple Binding 
Request because that could be interpreted as a connectivity check, which 
requires short-term auth. And you don't want to use short-term auth 
because it is too computationally intensive.

> |I'm not following you. ICE requires short-term auth for *connectivity
> |checks*. Those are done *before* ICE concludes. ICE does not require
> |short-term auth for Binding requests sent *after* ICE concludes. For
> |keepalives, it even says that auth must not be used.
>
> <snip from the RFC5245>
>     B.4.  Importance of the STUN Username
>
>     ICE requires the usage of message integrity with STUN using its
>     short-term credential functionality.  The actual short-term
>     credential is formed by exchanging username fragments in the SDP
>     offer/answer exchange.
>
>     B.10.  Why Are Binding Indications Used for Keepalives?
>
>     Additionally, using a Binding Indication allows integrity to be
>     disabled, allowing for better performance.  This is useful for large-
>     scale endpoints, such as PSTN gateways and SBCs.
> </snip>
>
> It doesn't look ICE intended to limit the message integrity and
> short-term auth for connectivity checks alone -- it looks applicable for
> any Binding request/response transaction.

This snippet should be explicit enough:

<snip from the RFC5245>
    If STUN is being used for keepalives, a STUN Binding Indication is
    used [RFC5389].  The Indication MUST NOT utilize any authentication
    mechanism.
</snip>

> <snip from the RFC5245>
>     10.  Keepalives
>     Though Binding Indications are used for keepalives,
>     an agent MUST be prepared to receive a connectivity check as well.
>     If a connectivity check is received, a response is generated as
>     discussed in [RFC5389], but there is no impact on ICE processing
>     otherwise.
> </snip>
>
> If a connectivity check is received for keepalive, it should use the
> message integrity and short-term auth, I think.

Ok, so once ICE concludes there are two messages one must be prepared to 
receive:
Binding Indication ==> keepalive ==> MUST NOT use auth
Binding Request ==> connectivity check ==> MUST use short-term auth

Could there be a way to relax the "MUST use short-term auth" 
requirement? The thing is that you need to be sure that your peer's ICE 
has concluded too. Once you know that then both of you are not 
vulnerable to media hijacking anymore, and at that point short-term auth 
would not be necessary anymore. I can't think of an existing way to know 
that right now, but with a new STUN message that could be possible. I'm 
thinking of an exchange going
"I'm done are you done?"
"yes I'm done"
---> short term auth no longer needed

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 ietfdbh@comcast.net  Wed Mar  7 06:08:45 2012
Return-Path: <ietfdbh@comcast.net>
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 3999621F879D for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 06:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.247
X-Spam-Level: 
X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jxxi6DB0m68 for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 06:08:44 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F321F877E for <behave@ietf.org>; Wed,  7 Mar 2012 06:08:41 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id idjH1i00C1uE5Es5De8hjL; Wed, 07 Mar 2012 14:08:41 +0000
Received: from [192.168.1.33] ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id ie8R1i0143Ecudz3ce8cav; Wed, 07 Mar 2012 14:08:41 +0000
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Wed, 07 Mar 2012 09:08:22 -0500
From: David Harrington <ietfdbh@comcast.net>
To: <behave@ietf.org>
Message-ID: <CB7CD5F2.1E1A3%ietfdbh@comcast.net>
Thread-Topic: [RFC State] <draft-ietf-behave-64-analysis-07> has been added to RFC Editor database
In-Reply-To: <20120307055640.7C4A6B1E003@rfc-editor.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [BEHAVE] FW: [RFC State] <draft-ietf-behave-64-analysis-07> has been added to RFC Editor database
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2012 14:08:45 -0000

Congratulations!

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
Ietfdbh@comcast.net
+1-603-828-1401





On 3/7/12 12:56 AM, "rfc-editor@rfc-editor.org"
<rfc-editor@rfc-editor.org> wrote:

>
>Author(s),
>
>We have received notice that your document
>draft-ietf-behave-64-analysis-07 has
>been approved for publication as an RFC.  The document has
>been added to the RFC-Editor queue and you can check the status at
><http://www.rfc-editor.org/queue2.html#draft-ietf-behave-64-analysis>
>
>** Note: Please see our News page
>** (http://www.rfc-editor.org/news.html) for information regarding the
>** transition to the RFC 5378 copyright notice and legends as it
>** relates to your document in the RFC Editor queue.
>
>If you submitted your XML file using the I-D submission tool, we have
>already retrieved it.  If you did not submit the XML file via the I-D
>submission tool, or if you have an updated version (e.g., updated
>contact information), please send us the XML file at this time. Please
>attach the file as draft-ietf-behave-64-analysis-07.xml, and specify
>any differences between the approved I-D and the document that the XML
>produces.
>
>If you created this document using -ms nroff, please send us the
>source file.
>
>This should help increase the pace with which documents move through
>the RFC-Editor queue.
>
>Please let us know if you have any questions.
>
>Thank you.
>
>The RFC-Editor Team
>



From Dmitry.Anipko@microsoft.com  Wed Mar  7 16:06:52 2012
Return-Path: <Dmitry.Anipko@microsoft.com>
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 28CF411E809A for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 16:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level: 
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRzakl8Iu-QQ for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 16:06:51 -0800 (PST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id A095C11E808C for <behave@ietf.org>; Wed,  7 Mar 2012 16:06:50 -0800 (PST)
Received: from mail65-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 00:06:49 +0000
Received: from mail65-am1 (localhost [127.0.0.1])	by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 86AC42C038B	for <behave@ietf.org>; Thu,  8 Mar 2012 00:06:49 +0000 (UTC)
X-SpamScore: -26
X-BigFish: VS-26(zz9371Ic85fh179cMzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail65-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1331165207298225_28836; Thu,  8 Mar 2012 00:06:47 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.225])	by mail65-am1.bigfish.com (Postfix) with ESMTP id 4507924005D	for <behave@ietf.org>; Thu,  8 Mar 2012 00:06:47 +0000 (UTC)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 00:06:45 +0000
Received: from TK5EX14MBXC238.redmond.corp.microsoft.com ([169.254.1.155]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 00:06:43 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: "behave@ietf.org" <behave@ietf.org>
Thread-Topic: NAT64: clarification on RST handling in V6 FIN RCV state
Thread-Index: Aczyijvg7tx51T/RTcC0uSBh3Nq7LQKNPLOA
Date: Thu, 8 Mar 2012 00:06:43 +0000
Message-ID: <03FE6A726D13284495EF1787D25F1DF91F84F766@TK5EX14MBXC238.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_03FE6A726D13284495EF1787D25F1DF91F84F766TK5EX14MBXC238r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Murari Sridharan <muraris@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 00:06:52 -0000

--_000_03FE6A726D13284495EF1787D25F1DF91F84F766TK5EX14MBXC238r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've not seen any responses, comments would be appreciated.

From: Dmitry Anipko
Sent: Thursday, February 23, 2012 4:21 PM
To: behave@ietf.org
Subject: NAT64: clarification on RST handling in V6 FIN RCV state

Hello,

RFC 6146, section 3.5.2.2, says that in V6 FIN RCV state *any* packet other=
 than V4 FIN must set the session lifetime to no less than TCP_EST=3D2hours=
.

If the V4 target sent RST in response to the translated V6 FIN, what is the=
 reason to keep the NAT mapping alive for TCP_EST instead of TCP_TRANS?

Should the language "if a V4 FIN packet is received,... lifetime is set to =
TCP_TRANS" be changed to "if a V4 FIN or V4 RST packet is received,... life=
time is set to TCP_TRANS"?

-Dmitry



--_000_03FE6A726D13284495EF1787D25F1DF91F84F766TK5EX14MBXC238r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"Section1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I&#8217;ve not seen an=
y responses, comments would be appreciated.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Dmitry A=
nipko
<br>
<b>Sent:</b> Thursday, February 23, 2012 4:21 PM<br>
<b>To:</b> behave@ietf.org<br>
<b>Subject:</b> NAT64: clarification on RST handling in V6 FIN RCV state<o:=
p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hello,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">RFC 6146, section 3.5.2.2, says that in V6 FIN RCV s=
tate *<b>any</b>* packet other than V4 FIN must set the session lifetime to=
 no less than TCP_EST=3D2hours.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">If the V4 target sent RST in response to the transla=
ted V6 FIN, what is the reason to keep the NAT mapping alive for TCP_EST in=
stead of TCP_TRANS?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Should the language &#8220;if a V4 FIN packet is rec=
eived,&#8230; lifetime is set to TCP_TRANS&#8221; be changed to &#8220;if a=
 V4 FIN or V4 RST packet is received,&#8230; lifetime is set to TCP_TRANS&#=
8221;?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">-Dmitry<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_03FE6A726D13284495EF1787D25F1DF91F84F766TK5EX14MBXC238r_--

From marcelo@it.uc3m.es  Wed Mar  7 22:27:12 2012
Return-Path: <marcelo@it.uc3m.es>
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 98D9221F8554 for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfANvoo42KYd for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:27:11 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 12F1121F8691 for <behave@ietf.org>; Wed,  7 Mar 2012 22:27:10 -0800 (PST)
X-uc3m-safe: yes
Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 188E6C27EE9; Thu,  8 Mar 2012 07:27:08 +0100 (CET)
Message-ID: <4F58513B.3010508@it.uc3m.es>
Date: Thu, 08 Mar 2012 07:27:07 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
References: <03FE6A726D13284495EF1787D25F1DF91F84F766@TK5EX14MBXC238.redmond.corp.microsoft.com>
In-Reply-To: <03FE6A726D13284495EF1787D25F1DF91F84F766@TK5EX14MBXC238.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18760.003
Cc: Murari Sridharan <muraris@microsoft.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 06:27:12 -0000

Hi Dimitry,

We had a long discussion about how to handle RST packets and the 
possibility of using an RST packet in a mailicious way was a concern, 
also considering that the nat64 is unable to determine how the host 
would handle the RST packet.
Because of this, we decided to go the conservative way and don't change 
the nat64 state upon the reception of a RST packet.

We also had a long discussion that there may be some more fine grained 
ways to deal with this depending whether it comes from the internal side 
or the external side.

The particular case you discuss i don't think we explicilty discussed 
it, but i guess it falls in the aforementioned case of higher 
granularity and my take is the same as above. It could be a reaosnable 
optimization, but it woudl increase the complexity of the implementation.

I hope this makes sense.

Regards, marcelo



El 08/03/12 01:06, Dmitry Anipko escribió:
>
> I’ve not seen any responses, comments would be appreciated.
>
> *From:*Dmitry Anipko
> *Sent:* Thursday, February 23, 2012 4:21 PM
> *To:* behave@ietf.org
> *Subject:* NAT64: clarification on RST handling in V6 FIN RCV state
>
> Hello,
>
> RFC 6146, section 3.5.2.2, says that in V6 FIN RCV state **any** 
> packet other than V4 FIN must set the session lifetime to no less than 
> TCP_EST=2hours.
>
> If the V4 target sent RST in response to the translated V6 FIN, what 
> is the reason to keep the NAT mapping alive for TCP_EST instead of 
> TCP_TRANS?
>
> Should the language “if a V4 FIN packet is received,… lifetime is set 
> to TCP_TRANS” be changed to “if a V4 FIN or V4 RST packet is 
> received,… lifetime is set to TCP_TRANS”?
>
> -Dmitry
>
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave


From marcelo@it.uc3m.es  Wed Mar  7 22:45:29 2012
Return-Path: <marcelo@it.uc3m.es>
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 4D81721E8017 for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SG3bt+-ditT for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:45:27 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47F21F862F for <behave@ietf.org>; Wed,  7 Mar 2012 22:45:27 -0800 (PST)
X-uc3m-safe: yes
Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 14B75C1BBB8; Thu,  8 Mar 2012 07:45:26 +0100 (CET)
Message-ID: <4F585585.9000706@it.uc3m.es>
Date: Thu, 08 Mar 2012 07:45:25 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Murari Sridharan <muraris@microsoft.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>
In-Reply-To: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18760.003
Cc: "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 06:45:29 -0000

Hi Murari,

I see what you mean now (and my previous answer was wrong, so please 
disregard it)

Yes it makes sense.

Do you have any hint that this will be a common case i.e. receiving a 
RST as reply to a FIN?

If it is not expected to be common, i guess the normal thing will be to 
receive a FIN on the other direction right away, so it may not worth the 
trouble.

Regards, marcelo



El 08/03/12 07:34, Murari Sridharan escribió:
> Marcelo,
> There is discussion about how to handle RST in ESTAB state by bouncing 
> off of TRANS essentially. Why cant the same thing apply to one of the 
> FIN RCV state? Meaning if there is a RST, again all the caveats below 
> apply, but bounce of TRANS see if the RST is accepted and further data 
> flows and either move to CLOSED or come back to the FIN RCV states?
> Thanks
> Sent from my Windows 8 PC <http://windows.microsoft.com/consumer-preview>
> *From:* marcelo bagnulo braun
> *Sent:* Wednesday, March 07, 2012 10:27:13 PM
> *To:* Dmitry Anipko
> *CC:* behave@ietf.org, Murari Sridharan
> *Subject:* Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN 
> RCV state
> Hi Dimitry,
>
> We had a long discussion about how to handle RST packets and the
> possibility of using an RST packet in a mailicious way was a concern,
> also considering that the nat64 is unable to determine how the host
> would handle the RST packet.
> Because of this, we decided to go the conservative way and don't change
> the nat64 state upon the reception of a RST packet.
>
> We also had a long discussion that there may be some more fine grained
> ways to deal with this depending whether it comes from the internal side
> or the external side.
>
> The particular case you discuss i don't think we explicilty discussed
> it, but i guess it falls in the aforementioned case of higher
> granularity and my take is the same as above. It could be a reaosnable
> optimization, but it woudl increase the complexity of the implementation.
>
> I hope this makes sense.
>
> Regards, marcelo
>
>
>
> El 08/03/12 01:06, Dmitry Anipko escribió:
> >
> > I’ve not seen any responses, comments would be appreciated.
> >
> > *From:*Dmitry Anipko
> > *Sent:* Thursday, February 23, 2012 4:21 PM
> > *To:* behave@ietf.org
> > *Subject:* NAT64: clarification on RST handling in V6 FIN RCV state
> >
> > Hello,
> >
> > RFC 6146, section 3.5.2.2, says that in V6 FIN RCV state **any**
> > packet other than V4 FIN must set the session lifetime to no less than
> > TCP_EST=2hours.
> >
> > If the V4 target sent RST in response to the translated V6 FIN, what
> > is the reason to keep the NAT mapping alive for TCP_EST instead of
> > TCP_TRANS?
> >
> > Should the language “if a V4 FIN packet is received,… lifetime is set
> > to TCP_TRANS� be changed to “if a V4 FIN or V4 RST packet is
> > received,… lifetime is set to TCP_TRANS�?
> >
> > -Dmitry
> >
> >
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
>
>


From internet-drafts@ietf.org  Thu Mar  8 02:34:36 2012
Return-Path: <internet-drafts@ietf.org>
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 9B44021F864F; Thu,  8 Mar 2012 02:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level: 
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbKeMdPiGMjg; Thu,  8 Mar 2012 02:34:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B8621F8639; Thu,  8 Mar 2012 02:34:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120308103434.12771.25069.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2012 02:34:34 -0800
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-learn-analysis-03.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 10:34:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Behavior Engineering for Hindrance Av=
oidance Working Group of the IETF.

	Title           : Analysis of solution proposals for hosts to learn NAT64 =
prefix
	Author(s)       : Jouni Korhonen
                          Teemu Savolainen
	Filename        : draft-ietf-behave-nat64-learn-analysis-03.txt
	Pages           : 25
	Date            : 2012-03-08

   Hosts and applications may benefit from the knowledge if an IPv6
   address is synthesized, which would mean a NAT64 is used to reach the
   IPv4 network or Internet.  This document analyses a number of
   proposed solutions for communicating whether the synthesis is taking
   place, used address format, and the IPv6 prefix used by the NAT64 and
   DNS64.  The solutions enable both NAT64 avoidance and intentional
   utilization by allowing local IPv6 address synthesis.  The document
   concludes by recommending selection of heuristic discovery based
   solution.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-=
03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-0=
3.txt


From iesg-secretary@ietf.org  Thu Mar  8 07:51:37 2012
Return-Path: <iesg-secretary@ietf.org>
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 C398521F86F8; Thu,  8 Mar 2012 07:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level: 
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpjV9Pk0l7id; Thu,  8 Mar 2012 07:51:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD56F21F86F4; Thu,  8 Mar 2012 07:51:36 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120308155136.30066.69798.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2012 07:51:36 -0800
Cc: behave@ietf.org
Subject: [BEHAVE] Last Call: <draft-ietf-behave-nat64-learn-analysis-03.txt> (Analysis	of solution proposals for hosts to learn NAT64 prefix) to	Informational RFC
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 15:51:38 -0000

The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'Analysis of solution proposals for hosts to learn NAT64 prefix'
  <draft-ietf-behave-nat64-learn-analysis-03.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Hosts and applications may benefit from the knowledge if an IPv6
   address is synthesized, which would mean a NAT64 is used to reach the
   IPv4 network or Internet.  This document analyses a number of
   proposed solutions for communicating whether the synthesis is taking
   place, used address format, and the IPv6 prefix used by the NAT64 and
   DNS64.  The solutions enable both NAT64 avoidance and intentional
   utilization by allowing local IPv6 address synthesis.  The document
   concludes by recommending selection of heuristic discovery based
   solution.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-learn-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-learn-analysis/ballot/


No IPR declarations have been submitted directly on this I-D.



From muraris@microsoft.com  Wed Mar  7 22:47:23 2012
Return-Path: <muraris@microsoft.com>
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 3ED2221E8040 for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.7
X-Spam-Level: 
X-Spam-Status: No, score=-104.7 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwx2RcXD+tzg for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:47:22 -0800 (PST)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2138221F8649 for <behave@ietf.org>; Wed,  7 Mar 2012 22:47:22 -0800 (PST)
Received: from mail107-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 06:47:21 +0000
Received: from mail107-db3 (localhost [127.0.0.1])	by mail107-db3-R.bigfish.com (Postfix) with ESMTP id 3563040340; Thu,  8 Mar 2012 06:47:21 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VS-38(zzbb2dI9371Ic89bh179cM1432Nzz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h946h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail107-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail107-db3 (localhost.localdomain [127.0.0.1]) by mail107-db3 (MessageSwitch) id 1331189237186437_25826; Thu,  8 Mar 2012 06:47:17 +0000 (UTC)
Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.226])	by mail107-db3.bigfish.com (Postfix) with ESMTP id 2A8A620045; Thu,  8 Mar 2012 06:47:17 +0000 (UTC)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 06:47:16 +0000
Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.119]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 06:47:14 +0000
From: Murari Sridharan <muraris@microsoft.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Thread-Topic: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
Thread-Index: Acz89Xq07tx51T/RTcC0uSBh3Nq7LQAAY/KAAAAFDls=
Date: Thu, 8 Mar 2012 06:47:13 +0000
Message-ID: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC2A5@TK5EX14MBXC298.redmond.corp.microsoft.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>, <4F585585.9000706@it.uc3m.es>
In-Reply-To: <4F585585.9000706@it.uc3m.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-Mailman-Approved-At: Thu, 08 Mar 2012 09:57:25 -0800
Cc: "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 06:47:23 -0000

It is very dependent on higher layer behavior, but we do see cases where th=
e close isn't graceful and we see a RST in response to a FIN.=20

Thanks

________________________________________
From: marcelo bagnulo braun [marcelo@it.uc3m.es]
Sent: Wednesday, March 07, 2012 10:45 PM
To: Murari Sridharan
Cc: Dmitry Anipko; behave@ietf.org
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV st=
ate

Hi Murari,

I see what you mean now (and my previous answer was wrong, so please
disregard it)

Yes it makes sense.

Do you have any hint that this will be a common case i.e. receiving a
RST as reply to a FIN?

If it is not expected to be common, i guess the normal thing will be to
receive a FIN on the other direction right away, so it may not worth the
trouble.

Regards, marcelo



El 08/03/12 07:34, Murari Sridharan escribi=F3:
> Marcelo,
> There is discussion about how to handle RST in ESTAB state by bouncing
> off of TRANS essentially. Why cant the same thing apply to one of the
> FIN RCV state? Meaning if there is a RST, again all the caveats below
> apply, but bounce of TRANS see if the RST is accepted and further data
> flows and either move to CLOSED or come back to the FIN RCV states?
> Thanks
> Sent from my Windows 8 PC <http://windows.microsoft.com/consumer-preview>
> *From:* marcelo bagnulo braun
> *Sent:* Wednesday, March 07, 2012 10:27:13 PM
> *To:* Dmitry Anipko
> *CC:* behave@ietf.org, Murari Sridharan
> *Subject:* Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN
> RCV state
> Hi Dimitry,
>
> We had a long discussion about how to handle RST packets and the
> possibility of using an RST packet in a mailicious way was a concern,
> also considering that the nat64 is unable to determine how the host
> would handle the RST packet.
> Because of this, we decided to go the conservative way and don't change
> the nat64 state upon the reception of a RST packet.
>
> We also had a long discussion that there may be some more fine grained
> ways to deal with this depending whether it comes from the internal side
> or the external side.
>
> The particular case you discuss i don't think we explicilty discussed
> it, but i guess it falls in the aforementioned case of higher
> granularity and my take is the same as above. It could be a reaosnable
> optimization, but it woudl increase the complexity of the implementation.
>
> I hope this makes sense.
>
> Regards, marcelo
>
>
>
> El 08/03/12 01:06, Dmitry Anipko escribi=F3:
> >
> > I=92ve not seen any responses, comments would be appreciated.
> >
> > *From:*Dmitry Anipko
> > *Sent:* Thursday, February 23, 2012 4:21 PM
> > *To:* behave@ietf.org
> > *Subject:* NAT64: clarification on RST handling in V6 FIN RCV state
> >
> > Hello,
> >
> > RFC 6146, section 3.5.2.2, says that in V6 FIN RCV state **any**
> > packet other than V4 FIN must set the session lifetime to no less than
> > TCP_EST=3D2hours.
> >
> > If the V4 target sent RST in response to the translated V6 FIN, what
> > is the reason to keep the NAT mapping alive for TCP_EST instead of
> > TCP_TRANS?
> >
> > Should the language =93if a V4 FIN packet is received,=85 lifetime is s=
et
> > to TCP_TRANS=94 be changed to =93if a V4 FIN or V4 RST packet is
> > received,=85 lifetime is set to TCP_TRANS=94?
> >
> > -Dmitry
> >
> >
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
>
>=


From muraris@microsoft.com  Wed Mar  7 22:34:22 2012
Return-Path: <muraris@microsoft.com>
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 8A95E21F869E for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y32i3am64j5x for <behave@ietfa.amsl.com>; Wed,  7 Mar 2012 22:34:21 -0800 (PST)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5D21F869A for <behave@ietf.org>; Wed,  7 Mar 2012 22:34:20 -0800 (PST)
Received: from mail6-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 06:34:20 +0000
Received: from mail6-db3 (localhost [127.0.0.1])	by mail6-db3-R.bigfish.com (Postfix) with ESMTP id 0A34820329; Thu,  8 Mar 2012 06:34:20 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VS-38(zzbb2dI9371Ic89bh179cM1432Nc857hzz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail6-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail6-db3 (localhost.localdomain [127.0.0.1]) by mail6-db3 (MessageSwitch) id 1331188458216741_28887; Thu,  8 Mar 2012 06:34:18 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.238])	by mail6-db3.bigfish.com (Postfix) with ESMTP id 24D1F380045; Thu,  8 Mar 2012 06:34:18 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 06:34:17 +0000
Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.119]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 06:34:15 +0000
From: Murari Sridharan <muraris@microsoft.com>
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>, marcelo bagnulo braun <marcelo@it.uc3m.es>
Thread-Topic: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
Thread-Index: Acz89Xq07tx51T/RTcC0uSBh3Nq7LQ==
Date: Thu, 8 Mar 2012 06:34:14 +0000
Message-ID: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6TK5EX14MBXC298r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-Mailman-Approved-At: Thu, 08 Mar 2012 09:57:25 -0800
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 06:34:22 -0000
X-List-Received-Date: Thu, 08 Mar 2012 06:34:22 -0000

--_000_EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6TK5EX14MBXC298r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TWFyY2VsbywNCg0KVGhlcmUgaXMgZGlzY3Vzc2lvbiBhYm91dCBob3cgdG8gaGFuZGxlIFJTVCBp
biBFU1RBQiBzdGF0ZSBieSBib3VuY2luZyBvZmYgb2YgVFJBTlMgZXNzZW50aWFsbHkuIFdoeSBj
YW50IHRoZSBzYW1lIHRoaW5nIGFwcGx5IHRvIG9uZSBvZiB0aGUgRklOIFJDViBzdGF0ZT8gTWVh
bmluZyBpZiB0aGVyZSBpcyBhIFJTVCwgYWdhaW4gYWxsIHRoZSBjYXZlYXRzIGJlbG93IGFwcGx5
LCBidXQgYm91bmNlIG9mIFRSQU5TIHNlZSBpZiB0aGUgUlNUIGlzIGFjY2VwdGVkIGFuZCBmdXJ0
aGVyIGRhdGEgZmxvd3MgYW5kIGVpdGhlciBtb3ZlIHRvIENMT1NFRCBvciBjb21lIGJhY2sgdG8g
dGhlIEZJTiBSQ1Ygc3RhdGVzPw0KDQpUaGFua3MNCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgOCBQ
QzxodHRwOi8vd2luZG93cy5taWNyb3NvZnQuY29tL2NvbnN1bWVyLXByZXZpZXc+DQoNCkZyb206
IG1hcmNlbG8gYmFnbnVsbyBicmF1bg0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNywgMjAxMiAx
MDoyNzoxMyBQTQ0KVG86IERtaXRyeSBBbmlwa28NCkNDOiBiZWhhdmVAaWV0Zi5vcmcsIE11cmFy
aSBTcmlkaGFyYW4NClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBOQVQ2NDogY2xhcmlmaWNhdGlvbiBv
biBSU1QgaGFuZGxpbmcgaW4gVjYgRklOIFJDViBzdGF0ZQ0KDQpIaSBEaW1pdHJ5LA0KDQpXZSBo
YWQgYSBsb25nIGRpc2N1c3Npb24gYWJvdXQgaG93IHRvIGhhbmRsZSBSU1QgcGFja2V0cyBhbmQg
dGhlDQpwb3NzaWJpbGl0eSBvZiB1c2luZyBhbiBSU1QgcGFja2V0IGluIGEgbWFpbGljaW91cyB3
YXkgd2FzIGEgY29uY2VybiwNCmFsc28gY29uc2lkZXJpbmcgdGhhdCB0aGUgbmF0NjQgaXMgdW5h
YmxlIHRvIGRldGVybWluZSBob3cgdGhlIGhvc3QNCndvdWxkIGhhbmRsZSB0aGUgUlNUIHBhY2tl
dC4NCkJlY2F1c2Ugb2YgdGhpcywgd2UgZGVjaWRlZCB0byBnbyB0aGUgY29uc2VydmF0aXZlIHdh
eSBhbmQgZG9uJ3QgY2hhbmdlDQp0aGUgbmF0NjQgc3RhdGUgdXBvbiB0aGUgcmVjZXB0aW9uIG9m
IGEgUlNUIHBhY2tldC4NCg0KV2UgYWxzbyBoYWQgYSBsb25nIGRpc2N1c3Npb24gdGhhdCB0aGVy
ZSBtYXkgYmUgc29tZSBtb3JlIGZpbmUgZ3JhaW5lZA0Kd2F5cyB0byBkZWFsIHdpdGggdGhpcyBk
ZXBlbmRpbmcgd2hldGhlciBpdCBjb21lcyBmcm9tIHRoZSBpbnRlcm5hbCBzaWRlDQpvciB0aGUg
ZXh0ZXJuYWwgc2lkZS4NCg0KVGhlIHBhcnRpY3VsYXIgY2FzZSB5b3UgZGlzY3VzcyBpIGRvbid0
IHRoaW5rIHdlIGV4cGxpY2lsdHkgZGlzY3Vzc2VkDQppdCwgYnV0IGkgZ3Vlc3MgaXQgZmFsbHMg
aW4gdGhlIGFmb3JlbWVudGlvbmVkIGNhc2Ugb2YgaGlnaGVyDQpncmFudWxhcml0eSBhbmQgbXkg
dGFrZSBpcyB0aGUgc2FtZSBhcyBhYm92ZS4gSXQgY291bGQgYmUgYSByZWFvc25hYmxlDQpvcHRp
bWl6YXRpb24sIGJ1dCBpdCB3b3VkbCBpbmNyZWFzZSB0aGUgY29tcGxleGl0eSBvZiB0aGUgaW1w
bGVtZW50YXRpb24uDQoNCkkgaG9wZSB0aGlzIG1ha2VzIHNlbnNlLg0KDQpSZWdhcmRzLCBtYXJj
ZWxvDQoNCg0KDQpFbCAwOC8wMy8xMiAwMTowNiwgRG1pdHJ5IEFuaXBrbyBlc2NyaWJpw7M6DQo+
DQo+IEnigJl2ZSBub3Qgc2VlbiBhbnkgcmVzcG9uc2VzLCBjb21tZW50cyB3b3VsZCBiZSBhcHBy
ZWNpYXRlZC4NCj4NCj4gKkZyb206KkRtaXRyeSBBbmlwa28NCj4gKlNlbnQ6KiBUaHVyc2RheSwg
RmVicnVhcnkgMjMsIDIwMTIgNDoyMSBQTQ0KPiAqVG86KiBiZWhhdmVAaWV0Zi5vcmcNCj4gKlN1
YmplY3Q6KiBOQVQ2NDogY2xhcmlmaWNhdGlvbiBvbiBSU1QgaGFuZGxpbmcgaW4gVjYgRklOIFJD
ViBzdGF0ZQ0KPg0KPiBIZWxsbywNCj4NCj4gUkZDIDYxNDYsIHNlY3Rpb24gMy41LjIuMiwgc2F5
cyB0aGF0IGluIFY2IEZJTiBSQ1Ygc3RhdGUgKiphbnkqKg0KPiBwYWNrZXQgb3RoZXIgdGhhbiBW
NCBGSU4gbXVzdCBzZXQgdGhlIHNlc3Npb24gbGlmZXRpbWUgdG8gbm8gbGVzcyB0aGFuDQo+IFRD
UF9FU1Q9MmhvdXJzLg0KPg0KPiBJZiB0aGUgVjQgdGFyZ2V0IHNlbnQgUlNUIGluIHJlc3BvbnNl
IHRvIHRoZSB0cmFuc2xhdGVkIFY2IEZJTiwgd2hhdA0KPiBpcyB0aGUgcmVhc29uIHRvIGtlZXAg
dGhlIE5BVCBtYXBwaW5nIGFsaXZlIGZvciBUQ1BfRVNUIGluc3RlYWQgb2YNCj4gVENQX1RSQU5T
Pw0KPg0KPiBTaG91bGQgdGhlIGxhbmd1YWdlIOKAnGlmIGEgVjQgRklOIHBhY2tldCBpcyByZWNl
aXZlZCzigKYgbGlmZXRpbWUgaXMgc2V0DQo+IHRvIFRDUF9UUkFOU+KAnSBiZSBjaGFuZ2VkIHRv
IOKAnGlmIGEgVjQgRklOIG9yIFY0IFJTVCBwYWNrZXQgaXMNCj4gcmVjZWl2ZWQs4oCmIGxpZmV0
aW1lIGlzIHNldCB0byBUQ1BfVFJBTlPigJ0/DQo+DQo+IC1EbWl0cnkNCj4NCj4NCj4NCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQmVoYXZlIG1h
aWxpbmcgbGlzdA0KPiBCZWhhdmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9iZWhhdmUNCg0KDQo=

--_000_EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6TK5EX14MBXC298r_
Content-Type: text/html; charset="utf-8"
Content-ID: <CB6E9CA2EB74E34CAB402777A1695E26@microsoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSxWZXJkYW5hLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmO2Zv
bnQtc2l6ZToxNC42NnB4OyI+DQo8ZGl2Pk1hcmNlbG8sIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp
dj4NCjxkaXY+VGhlcmUgaXMgZGlzY3Vzc2lvbiBhYm91dCBob3cgdG8gaGFuZGxlIFJTVCBpbiBF
U1RBQiBzdGF0ZSBieSBib3VuY2luZyBvZmYgb2YgVFJBTlMgZXNzZW50aWFsbHkuIFdoeSBjYW50
IHRoZSBzYW1lIHRoaW5nIGFwcGx5IHRvIG9uZSBvZiB0aGUgRklOIFJDViBzdGF0ZT8gTWVhbmlu
ZyBpZiB0aGVyZSBpcyBhIFJTVCwgYWdhaW4gYWxsIHRoZSBjYXZlYXRzIGJlbG93IGFwcGx5LCBi
dXQgYm91bmNlIG9mIFRSQU5TIHNlZSBpZiB0aGUgUlNUDQogaXMgYWNjZXB0ZWQgYW5kIGZ1cnRo
ZXIgZGF0YSBmbG93cyBhbmQgZWl0aGVyIG1vdmUgdG8gQ0xPU0VEIG9yIGNvbWUgYmFjayB0byB0
aGUgRklOIFJDViBzdGF0ZXM/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3M8
L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlNlbnQgZnJvbSBteSA8YSBocmVmPSJodHRw
Oi8vd2luZG93cy5taWNyb3NvZnQuY29tL2NvbnN1bWVyLXByZXZpZXciPldpbmRvd3MgOCBQQzwv
YT4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9w
LWNvbG9yOiByZ2IoMjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6IDJweDsgYm9yZGVy
LXRvcC1zdHlsZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4mbmJzcDttYXJjZWxv
IGJhZ251bG8gYnJhdW48YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+Jm5ic3A7V2VkbmVzZGF5
LCBNYXJjaCAwNywgMjAxMiAxMDoyNzoxMyBQTTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5i
c3A7RG1pdHJ5IEFuaXBrbzxicj4NCjxzdHJvbmc+Q0M6PC9zdHJvbmc+Jm5ic3A7YmVoYXZlQGll
dGYub3JnLCBNdXJhcmkgU3JpZGhhcmFuPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZu
YnNwO1JlOiBbQkVIQVZFXSBOQVQ2NDogY2xhcmlmaWNhdGlvbiBvbiBSU1QgaGFuZGxpbmcgaW4g
VjYgRklOIFJDViBzdGF0ZTxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCkhpIERpbWl0
cnksPGJyPg0KPGJyPg0KV2UgaGFkIGEgbG9uZyBkaXNjdXNzaW9uIGFib3V0IGhvdyB0byBoYW5k
bGUgUlNUIHBhY2tldHMgYW5kIHRoZSA8YnI+DQpwb3NzaWJpbGl0eSBvZiB1c2luZyBhbiBSU1Qg
cGFja2V0IGluIGEgbWFpbGljaW91cyB3YXkgd2FzIGEgY29uY2VybiwgPGJyPg0KYWxzbyBjb25z
aWRlcmluZyB0aGF0IHRoZSBuYXQ2NCBpcyB1bmFibGUgdG8gZGV0ZXJtaW5lIGhvdyB0aGUgaG9z
dCA8YnI+DQp3b3VsZCBoYW5kbGUgdGhlIFJTVCBwYWNrZXQuPGJyPg0KQmVjYXVzZSBvZiB0aGlz
LCB3ZSBkZWNpZGVkIHRvIGdvIHRoZSBjb25zZXJ2YXRpdmUgd2F5IGFuZCBkb24ndCBjaGFuZ2Ug
PGJyPg0KdGhlIG5hdDY0IHN0YXRlIHVwb24gdGhlIHJlY2VwdGlvbiBvZiBhIFJTVCBwYWNrZXQu
PGJyPg0KPGJyPg0KV2UgYWxzbyBoYWQgYSBsb25nIGRpc2N1c3Npb24gdGhhdCB0aGVyZSBtYXkg
YmUgc29tZSBtb3JlIGZpbmUgZ3JhaW5lZCA8YnI+DQp3YXlzIHRvIGRlYWwgd2l0aCB0aGlzIGRl
cGVuZGluZyB3aGV0aGVyIGl0IGNvbWVzIGZyb20gdGhlIGludGVybmFsIHNpZGUgPGJyPg0Kb3Ig
dGhlIGV4dGVybmFsIHNpZGUuPGJyPg0KPGJyPg0KVGhlIHBhcnRpY3VsYXIgY2FzZSB5b3UgZGlz
Y3VzcyBpIGRvbid0IHRoaW5rIHdlIGV4cGxpY2lsdHkgZGlzY3Vzc2VkIDxicj4NCml0LCBidXQg
aSBndWVzcyBpdCBmYWxscyBpbiB0aGUgYWZvcmVtZW50aW9uZWQgY2FzZSBvZiBoaWdoZXIgPGJy
Pg0KZ3JhbnVsYXJpdHkgYW5kIG15IHRha2UgaXMgdGhlIHNhbWUgYXMgYWJvdmUuIEl0IGNvdWxk
IGJlIGEgcmVhb3NuYWJsZSA8YnI+DQpvcHRpbWl6YXRpb24sIGJ1dCBpdCB3b3VkbCBpbmNyZWFz
ZSB0aGUgY29tcGxleGl0eSBvZiB0aGUgaW1wbGVtZW50YXRpb24uPGJyPg0KPGJyPg0KSSBob3Bl
IHRoaXMgbWFrZXMgc2Vuc2UuPGJyPg0KPGJyPg0KUmVnYXJkcywgbWFyY2Vsbzxicj4NCjxicj4N
Cjxicj4NCjxicj4NCkVsIDA4LzAzLzEyIDAxOjA2LCBEbWl0cnkgQW5pcGtvIGVzY3JpYmnDszo8
YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ4oCZdmUgbm90IHNlZW4gYW55IHJlc3BvbnNlcywgY29tbWVu
dHMgd291bGQgYmUgYXBwcmVjaWF0ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgKkZyb206KkRtaXRy
eSBBbmlwa288YnI+DQomZ3Q7ICpTZW50OiogVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDEyIDQ6
MjEgUE08YnI+DQomZ3Q7ICpUbzoqIGJlaGF2ZUBpZXRmLm9yZzxicj4NCiZndDsgKlN1YmplY3Q6
KiBOQVQ2NDogY2xhcmlmaWNhdGlvbiBvbiBSU1QgaGFuZGxpbmcgaW4gVjYgRklOIFJDViBzdGF0
ZTxicj4NCiZndDs8YnI+DQomZ3Q7IEhlbGxvLDxicj4NCiZndDs8YnI+DQomZ3Q7IFJGQyA2MTQ2
LCBzZWN0aW9uIDMuNS4yLjIsIHNheXMgdGhhdCBpbiBWNiBGSU4gUkNWIHN0YXRlICoqYW55Kiog
PGJyPg0KJmd0OyBwYWNrZXQgb3RoZXIgdGhhbiBWNCBGSU4gbXVzdCBzZXQgdGhlIHNlc3Npb24g
bGlmZXRpbWUgdG8gbm8gbGVzcyB0aGFuIDxicj4NCiZndDsgVENQX0VTVD0yaG91cnMuPGJyPg0K
Jmd0Ozxicj4NCiZndDsgSWYgdGhlIFY0IHRhcmdldCBzZW50IFJTVCBpbiByZXNwb25zZSB0byB0
aGUgdHJhbnNsYXRlZCBWNiBGSU4sIHdoYXQgPGJyPg0KJmd0OyBpcyB0aGUgcmVhc29uIHRvIGtl
ZXAgdGhlIE5BVCBtYXBwaW5nIGFsaXZlIGZvciBUQ1BfRVNUIGluc3RlYWQgb2YgPGJyPg0KJmd0
OyBUQ1BfVFJBTlM/PGJyPg0KJmd0Ozxicj4NCiZndDsgU2hvdWxkIHRoZSBsYW5ndWFnZSDigJxp
ZiBhIFY0IEZJTiBwYWNrZXQgaXMgcmVjZWl2ZWQs4oCmIGxpZmV0aW1lIGlzIHNldCA8YnI+DQom
Z3Q7IHRvIFRDUF9UUkFOU+KAnSBiZSBjaGFuZ2VkIHRvIOKAnGlmIGEgVjQgRklOIG9yIFY0IFJT
VCBwYWNrZXQgaXMgPGJyPg0KJmd0OyByZWNlaXZlZCzigKYgbGlmZXRpbWUgaXMgc2V0IHRvIFRD
UF9UUkFOU+KAnT88YnI+DQomZ3Q7PGJyPg0KJmd0OyAtRG1pdHJ5PGJyPg0KJmd0Ozxicj4NCiZn
dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCiZndDsgQmVoYXZlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQmVo
YXZlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2JlaGF2ZTxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6TK5EX14MBXC298r_--

From fred@cisco.com  Thu Mar  8 02:48:25 2012
Return-Path: <fred@cisco.com>
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 A040F21F8611 for <behave@ietfa.amsl.com>; Thu,  8 Mar 2012 02:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.939
X-Spam-Level: 
X-Spam-Status: No, score=-108.939 tagged_above=-999 required=5 tests=[AWL=1.660, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC1DZFKfRpxK for <behave@ietfa.amsl.com>; Thu,  8 Mar 2012 02:48:13 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8921F85F6 for <behave@ietf.org>; Thu,  8 Mar 2012 02:48:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=209434; q=dns/txt; s=iport; t=1331203693; x=1332413293; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=WAHqJKjjbjIFxRHJX3vcl1Sj1WFWvDdwDRuNUJxnd8M=; b=DqPuLVLInpSSaZ72R+GrEx+jfpFrRyyesP4++17Acvx+knINM/HpRtMs oEGqfK1GKYFupy3lnIBucyVoReJMyMO45eGfj4zg7qt4T6HWR8KIzHC+8 QI3OnpRWtzIz3AWx5FXuNYc5z/9QB7e02X0Sr/irq5u0ASD+SX3Nzsj+4 Q=;
X-Files: 10.71.5.180.60357.txt, 10.71.5.180.60356.txt, 10.71.5.180.60355.txt,  10.71.5.180.60354.txt, 10.71.5.180.60353.txt, 10.71.5.180.60275.txt : 40475, 42751, 59188, 25226, 22418, 8835
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmsFADiOWE+rRDoJ/2dsb2JhbABCsieBGIF0gQeCCgEBAQMBEgEHAV4FCwtGVwYxBIdhBKAAAZcviiiFY2MEiFCGBYZshWSKM4JygU0
X-IronPort-AV: E=Sophos;i="4.73,551,1325462400";  d="txt'?scan'208";a="35130613"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Mar 2012 10:47:58 +0000
Received: from Freds-Computer.local (tky-vpn-client-230-92.cisco.com [10.70.230.92]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28Alu6L021330; Thu, 8 Mar 2012 10:47:56 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 19:47:57 +0900
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 19:47:57 +0900
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4F585585.9000706@it.uc3m.es>
Date: Thu, 8 Mar 2012 19:47:44 +0900
Message-Id: <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com> <4F585585.9000706@it.uc3m.es>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
X-Mailer: Apple Mail (2.1084)
Content-Type: multipart/mixed; boundary=Apple-Mail-105-709146384
X-Mailman-Approved-At: Thu, 08 Mar 2012 09:57:25 -0800
Cc: Murari Sridharan <muraris@microsoft.com>, "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 10:48:25 -0000

--Apple-Mail-105-709146384
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Mar 8, 2012, at 3:45 PM, marcelo bagnulo braun wrote:

> Do you have any hint that this will be a common case i.e. receiving a =
RST as reply to a FIN?

I see them in traces. Yes, they happen. It's not what RFC 793 says, but =
it is often reality.

Last week, for example, I was trying to show a colleague what a long TCP =
trace looked like. I opened tcpdump and uploaded a picture to picasa. =
While that was happening, who knows what else my system was doing. In =
the tcpdump, I found 127 separate TCP sessions. Take a look at the =
trailing packets in the attached.

I didn't find a FIN (F without Ack) in any of the examples. I can send =
you the trace if you're interested.



--Apple-Mail-105-709146384
Content-Disposition: attachment;
	filename=10.71.5.180.60357.txt
Content-Type: text/plain;
	name="10.71.5.180.60357.txt"
Content-Transfer-Encoding: quoted-printable

06:35:44.191740 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [P.], =
seq 3246088630:3246088709, ack 2301194116, win 8576, options [nop,nop,TS =
val 1245062702 ecr 949460745], length 79
06:35:44.191756 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460785 ecr =
1245061749,nop,nop,sack 1 {0:79}], length 0
06:35:44.192027 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [P.], =
seq 79:159, ack 1, win 8576, options [nop,nop,TS val 1245062702 ecr =
949460745], length 80
06:35:44.192040 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460785 ecr =
1245061749,nop,nop,sack 1 {0:159}], length 0
06:35:44.192761 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [P.], =
seq 4294966734:0, ack 1, win 8576, options [nop,nop,TS val 1245062702 =
ecr 949460745], length 562
06:35:44.192776 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 159, win 65535, options [nop,nop,TS val 949460785 ecr 1245062702], =
length 0
06:35:44.315035 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 159:1607, ack 1, win 8576, options [nop,nop,TS val 1245062734 ecr =
949460785], length 1448
06:35:44.318521 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 1607:3055, ack 1, win 8576, options [nop,nop,TS val 1245062734 ecr =
949460785], length 1448
06:35:44.318536 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 3055, win 64638, options [nop,nop,TS val 949460786 ecr 1245062734], =
length 0
06:35:44.320805 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 3055:4503, ack 1, win 8576, options [nop,nop,TS val 1245062734 ecr =
949460785], length 1448
06:35:44.321897 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 4503:5951, ack 1, win 8576, options [nop,nop,TS val 1245062734 ecr =
949460785], length 1448
06:35:44.321911 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 5951, win 65160, options [nop,nop,TS val 949460786 ecr 1245062734], =
length 0
06:35:44.431754 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 5951:7399, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.432352 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 7399:8847, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.432367 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 8847, win 63712, options [nop,nop,TS val 949460787 ecr 1245062765], =
length 0
06:35:44.432925 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 8847:10295, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.433720 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 10295:11743, ack 1, win 8576, options [nop,nop,TS val 1245062766 ecr =
949460786], length 1448
06:35:44.434218 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 11743, win 63718, options [nop,nop,TS val 949460787 ecr 1245062765], =
length 0
06:35:44.434313 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 11743:13191, ack 1, win 8576, options [nop,nop,TS val 1245062766 ecr =
949460786], length 1448
06:35:44.435048 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 13191:14639, ack 1, win 8576, options [nop,nop,TS val 1245062766 ecr =
949460786], length 1448
06:35:44.435718 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 14639, win 63723, options [nop,nop,TS val 949460787 ecr 1245062766], =
length 0
06:35:44.548358 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 14639:16087, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.548460 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 16087, win 65192, options [nop,nop,TS val 949460788 ecr 1245062794], =
length 0
06:35:44.551955 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 16087:17535, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.552344 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 17535:18983, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.552663 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 18983, win 65201, options [nop,nop,TS val 949460788 ecr 1245062794], =
length 0
06:35:44.552953 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 18983:20431, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.555158 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 20431:21879, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.555175 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 21879, win 65160, options [nop,nop,TS val 949460788 ecr 1245062794], =
length 0
06:35:44.555754 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 21879:23327, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.556346 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 23327:24775, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.556721 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 24775:26223, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.556740 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 26223, win 63713, options [nop,nop,TS val 949460788 ecr 1245062794], =
length 0
06:35:44.557092 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 26223:27671, ack 1, win 8576, options [nop,nop,TS val 1245062794 ecr =
949460787], length 1448
06:35:44.558726 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 27671, win 65176, options [nop,nop,TS val 949460788 ecr 1245062794], =
length 0
06:35:44.673344 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 27671:29119, ack 1, win 8576, options [nop,nop,TS val 1245062823 ecr =
949460788], length 1448
06:35:44.674730 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 29119:30567, ack 1, win 8576, options [nop,nop,TS val 1245062823 ecr =
949460788], length 1448
06:35:44.674785 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 30567, win 65190, options [nop,nop,TS val 949460789 ecr 1245062823], =
length 0
06:35:44.675222 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 30567:32015, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.675655 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 32015:33463, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.676166 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 33463, win 65204, options [nop,nop,TS val 949460789 ecr 1245062825], =
length 0
06:35:44.676469 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 33463:34911, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.676483 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 34911, win 64337, options [nop,nop,TS val 949460789 ecr 1245062825], =
length 0
06:35:44.677935 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 34911:36359, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.679019 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 36359:37807, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.679055 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 37807, win 65171, options [nop,nop,TS val 949460789 ecr 1245062825], =
length 0
06:35:44.679655 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 37807:39255, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.680111 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 39255:40703, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.680411 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 40703, win 65177, options [nop,nop,TS val 949460789 ecr 1245062825], =
length 0
06:35:44.680561 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 40703:42151, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.681361 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 42151:43599, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.681933 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 43599:45047, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.682124 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 45047, win 63742, options [nop,nop,TS val 949460789 ecr 1245062825], =
length 0
06:35:44.682484 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 45047:46495, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.683262 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 46495:47943, ack 1, win 8576, options [nop,nop,TS val 1245062825 ecr =
949460788], length 1448
06:35:44.683277 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 47943, win 62806, options [nop,nop,TS val 949460789 ecr 1245062825], =
length 0
06:35:44.792600 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 47943:49391, ack 1, win 8576, options [nop,nop,TS val 1245062854 ecr =
949460789], length 1448
06:35:44.794261 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 49391, win 65170, options [nop,nop,TS val 949460791 ecr 1245062854], =
length 0
06:35:44.799398 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 49391:50839, ack 1, win 8576, options [nop,nop,TS val 1245062854 ecr =
949460789], length 1448
06:35:44.800486 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 50839:52287, ack 1, win 8576, options [nop,nop,TS val 1245062854 ecr =
949460789], length 1448
06:35:44.801184 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 52287, win 65178, options [nop,nop,TS val 949460791 ecr 1245062854], =
length 0
06:35:44.802654 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 52287:53735, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.803083 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 53735:55183, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.803939 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 55183, win 65195, options [nop,nop,TS val 949460791 ecr 1245062855], =
length 0
06:35:44.804294 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 55183:56631, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.805011 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 56631:58079, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.805442 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 58079:59527, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.805472 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 59527, win 63749, options [nop,nop,TS val 949460791 ecr 1245062855], =
length 0
06:35:44.810099 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 59527:60975, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.810135 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 60975, win 65160, options [nop,nop,TS val 949460791 ecr 1245062855], =
length 0
06:35:44.810698 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 60975:62423, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.811150 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 62423:63871, ack 1, win 8576, options [nop,nop,TS val 1245062855 ecr =
949460789], length 1448
06:35:44.811617 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 63871, win 65167, options [nop,nop,TS val 949460791 ecr 1245062855], =
length 0
06:35:44.811644 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 63871:65319, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.812299 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 65319:66767, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.812813 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 66767:68215, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.813080 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 68215, win 63721, options [nop,nop,TS val 949460791 ecr 1245062856], =
length 0
06:35:44.813364 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 68215:69663, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.814101 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 69663:71111, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.814597 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 71111, win 63738, options [nop,nop,TS val 949460791 ecr 1245062856], =
length 0
06:35:44.814773 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 71111:72559, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.815146 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 72559:74007, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.815159 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 74007, win 61944, options [nop,nop,TS val 949460791 ecr 1245062856], =
length 0
06:35:44.815864 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 74007:75455, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.816537 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 75455:76903, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.816587 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 76903, win 61945, options [nop,nop,TS val 949460791 ecr 1245062856], =
length 0
06:35:44.817134 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 76903:78351, ack 1, win 8576, options [nop,nop,TS val 1245062856 ecr =
949460789], length 1448
06:35:44.818126 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 78351, win 63396, options [nop,nop,TS val 949460791 ecr 1245062856], =
length 0
06:35:44.924712 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 78351:79799, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.924755 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 79799, win 65162, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.925490 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 79799:81247, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.925985 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 81247:82695, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.926149 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 82695, win 65164, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.926496 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 82695:84143, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.927151 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 84143:85591, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.927386 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 85591, win 65171, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.927786 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 85591:87039, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.927801 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 87039, win 64649, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.928640 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 87039:88487, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.929132 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 88487:89935, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.929163 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 89935, win 64830, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.929525 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 89935:91383, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.929939 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 91383:92831, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.930415 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 92831, win 64839, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.930518 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 92831:94279, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.930888 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 94279:95727, ack 1, win 8576, options [nop,nop,TS val 1245062887 ecr =
949460791], length 1448
06:35:44.931732 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 95727:97175, ack 1, win 8576, options [nop,nop,TS val 1245062890 ecr =
949460791], length 1448
06:35:44.932172 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 97175, win 63398, options [nop,nop,TS val 949460792 ecr 1245062887], =
length 0
06:35:44.935622 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 97175:98623, ack 1, win 8576, options [nop,nop,TS val 1245062890 ecr =
949460791], length 1448
06:35:44.936086 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 98623, win 65176, options [nop,nop,TS val 949460792 ecr 1245062890], =
length 0
06:35:44.937516 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 98623:100071, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.937530 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 100071, win 65160, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.939597 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 100071:101519, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.940548 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 101519:102967, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.941083 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 102967, win 65169, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.941754 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 102967:104415, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.942128 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 104415:105863, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.942484 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 105863, win 65175, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.942800 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 105863:107311, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.943498 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 107311:108759, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.943868 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 108759, win 65182, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.944130 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 108759:110207, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.945653 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 110207:111655, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.945904 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 111655, win 65183, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.946447 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 111655:113103, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.946462 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 113103, win 64984, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.948038 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 113103:114551, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.950100 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 114551:115999, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.950135 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 115999, win 65167, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.950386 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 115999:117447, ack 1, win 8576, options [nop,nop,TS val 1245062890 =
ecr 949460791], length 1448
06:35:44.951064 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 117447:118895, ack 1, win 8576, options [nop,nop,TS val 1245062892 =
ecr 949460791], length 1448
06:35:44.951480 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 118895, win 65173, options [nop,nop,TS val 949460792 ecr =
1245062890], length 0
06:35:44.951554 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 118895:120343, ack 1, win 8576, options [nop,nop,TS val 1245062892 =
ecr 949460791], length 1448
06:35:44.952231 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 120343:121791, ack 1, win 8576, options [nop,nop,TS val 1245062892 =
ecr 949460791], length 1448
06:35:44.952605 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 121791:123239, ack 1, win 8576, options [nop,nop,TS val 1245062892 =
ecr 949460791], length 1448
06:35:44.952750 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 123239, win 63725, options [nop,nop,TS val 949460792 ecr =
1245062892], length 0
06:35:44.953419 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 123239:124687, ack 1, win 8576, options [nop,nop,TS val 1245062892 =
ecr 949460791], length 1448
06:35:44.954060 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 124687, win 65173, options [nop,nop,TS val 949460792 ecr =
1245062892], length 0
06:35:45.048019 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 124687:126135, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.048033 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 126135, win 65160, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.049389 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 126135:127583, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.050333 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 127583:129031, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.051503 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 129031:130479, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.052311 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 130479:131927, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.052409 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 131927, win 62311, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.053788 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 131927, win 65224, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.053947 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 131927:133375, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.055556 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 133375:134823, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.056766 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 134823:136271, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.059710 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 136271:137719, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.059875 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 137719, win 62329, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.060916 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 137719:139167, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.060931 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 139167, win 62823, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.062204 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 139167:140615, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.062965 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 140615, win 64279, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.064141 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 140615:142063, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.064931 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 142063:143511, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.065348 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 143511:144959, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.065776 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 144959:146407, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.066391 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 146407:147855, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.066516 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 147855, win 59939, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.066823 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 147855:149303, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.067641 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 149303:150751, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.068171 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 150751:152199, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.068186 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 152199, win 58165, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.068867 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 152199:153647, ack 1, win 8576, options [nop,nop,TS val 1245062919 =
ecr 949460792], length 1448
06:35:45.069520 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 153647, win 59619, options [nop,nop,TS val 949460793 ecr =
1245062919], length 0
06:35:45.069566 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 153647:155095, ack 1, win 8576, options [nop,nop,TS val 1245062920 =
ecr 949460792], length 1448
06:35:45.070342 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 155095:156543, ack 1, win 8576, options [nop,nop,TS val 1245062920 =
ecr 949460792], length 1448
06:35:45.070876 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 156543:157991, ack 1, win 8576, options [nop,nop,TS val 1245062920 =
ecr 949460792], length 1448
06:35:45.070937 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 157991, win 58178, options [nop,nop,TS val 949460793 ecr =
1245062920], length 0
06:35:45.071550 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 157991:159439, ack 1, win 8576, options [nop,nop,TS val 1245062920 =
ecr 949460792], length 1448
06:35:45.072225 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 159439:160887, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.072326 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 160887, win 58185, options [nop,nop,TS val 949460793 ecr =
1245062920], length 0
06:35:45.072985 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 160887:162335, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.073233 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 162335:163783, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.073767 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 163783:165231, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.073782 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 165231, win 56253, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.074607 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 165231:166679, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.075097 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 166679, win 57705, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.075341 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 166679:168127, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.076403 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 168127, win 59155, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.077661 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 168127, win 62068, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.078915 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 168127, win 64965, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.079170 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 168127:169575, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.079909 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 169575:171023, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.080183 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 171023, win 64976, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.080379 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 171023:172471, ack 1, win 8576, options [nop,nop,TS val 1245062921 =
ecr 949460792], length 1448
06:35:45.081096 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 172471:173919, ack 1, win 8576, options [nop,nop,TS val 1245062922 =
ecr 949460792], length 1448
06:35:45.081493 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 173919, win 64998, options [nop,nop,TS val 949460793 ecr =
1245062921], length 0
06:35:45.081548 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 173919:175367, ack 1, win 8576, options [nop,nop,TS val 1245062922 =
ecr 949460792], length 1448
06:35:45.081922 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 175367:176815, ack 1, win 8576, options [nop,nop,TS val 1245062922 =
ecr 949460792], length 1448
06:35:45.082764 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 176815, win 65004, options [nop,nop,TS val 949460793 ecr =
1245062922], length 0
06:35:45.086877 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 178263, win 65160, options [nop,nop,TS val 949460793 ecr =
1245062923], length 0
06:35:45.088669 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 181159, win 65162, options [nop,nop,TS val 949460793 ecr =
1245062923], length 0
06:35:45.089951 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 184055, win 65162, options [nop,nop,TS val 949460793 ecr =
1245062923], length 0
06:35:45.092459 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 185503, win 65160, options [nop,nop,TS val 949460793 ecr =
1245062924], length 0
06:35:45.093936 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 188399, win 65168, options [nop,nop,TS val 949460794 ecr =
1245062924], length 0
06:35:45.183971 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [P.], =
seq 189847:191295, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.184022 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 191295, win 65160, options [nop,nop,TS val 949460794 ecr =
1245062924], length 0
06:35:45.184349 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 191295:192743, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.184923 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 192743:194191, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.185560 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 194191:195639, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.186030 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 195639:197087, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.186114 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 197087, win 62265, options [nop,nop,TS val 949460794 ecr =
1245062954], length 0
06:35:45.186820 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 197087:198535, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.187237 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 198535:199983, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.187609 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 199983, win 62287, options [nop,nop,TS val 949460794 ecr =
1245062954], length 0
06:35:45.187889 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 199983:201431, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.188771 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 201431:202879, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.189018 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 202879, win 62303, options [nop,nop,TS val 949460794 ecr =
1245062954], length 0
06:35:45.189689 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 202879:204327, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.189703 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 204327, win 62189, options [nop,nop,TS val 949460794 ecr =
1245062954], length 0
06:35:45.190100 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 204327:205775, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.191116 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 205775, win 63654, options [nop,nop,TS val 949460794 ecr =
1245062954], length 0
06:35:45.194591 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 205775:207223, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.194616 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 207223, win 65160, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.195167 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 207223:208671, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.195747 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 208671:210119, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.195764 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 210119, win 64204, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.196171 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 210119:211567, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.203207 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 211567:213015, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.203234 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 213015, win 65160, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.203587 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 213015:214463, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.204262 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 214463:215911, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.204276 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 215911, win 64205, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.204873 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 215911:217359, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.205388 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 217359:218807, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.205828 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 218807, win 64208, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.208431 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 218807:220255, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.209337 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 220255:221703, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.210529 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 221703:223151, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.213517 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 223151:224599, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.214214 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 224599:226047, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.214866 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
seq 226047:227495, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.215874 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [P.], =
seq 227495:228436, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 941
06:35:45.215888 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 228436, win 56979, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.217789 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 228436, win 59883, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.219536 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [.], =
ack 228436, win 62779, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:47.021523 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [P.], =
seq 1:24, ack 228436, win 65535, options [nop,nop,TS val 949460813 ecr =
1245062955], length 23
06:35:47.021552 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 228436, win 65535, options [nop,nop,TS val 949460813 ecr =
1245062955], length 0
06:35:47.088808 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [P.], =
seq 228436:228459, ack 1, win 8576, options [nop,nop,TS val 1245063429 =
ecr 949460795], length 23
06:35:47.088813 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [F.], =
seq 228459, ack 1, win 8576, options [nop,nop,TS val 1245063429 ecr =
949460795], length 0
06:35:47.088898 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [R], =
seq 2301194116, win 0, length 0
06:35:47.088929 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [R], =
seq 2301194116, win 0, length 0
06:35:47.139113 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
ack 24, win 8576, options [nop,nop,TS val 1245063441 ecr 949460813], =
length 0
06:35:47.139134 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [R], =
seq 2301194139, win 0, length 0
06:35:47.140386 IP mail.ietf.org.https > 10.71.5.180.60357: Flags [.], =
ack 25, win 8576, options [nop,nop,TS val 1245063441 ecr 949460813], =
length 0
06:35:47.140402 IP 10.71.5.180.60357 > mail.ietf.org.https: Flags [R], =
seq 2301194140, win 0, length 0

--Apple-Mail-105-709146384
Content-Disposition: attachment;
	filename=10.71.5.180.60356.txt
Content-Type: text/plain;
	name="10.71.5.180.60356.txt"
Content-Transfer-Encoding: quoted-printable

06:35:44.394344 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 2937763155:2937763234, ack 2152838196, win 8576, options [nop,nop,TS =
val 1245062754 ecr 949460745], length 79
06:35:44.394377 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460787 ecr =
1245061749,nop,nop,sack 1 {0:79}], length 0
06:35:44.394560 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 4294966734:0, ack 1, win 8576, options [nop,nop,TS val 1245062754 =
ecr 949460745], length 562
06:35:44.394578 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 79, win 65535, options [nop,nop,TS val 949460787 ecr 1245062754], =
length 0
06:35:44.395072 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 79:159, ack 1, win 8576, options [nop,nop,TS val 1245062754 ecr =
949460745], length 80
06:35:44.395089 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 159, win 65535, options [nop,nop,TS val 949460787 ecr 1245062754], =
length 0
06:35:44.529175 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 159:1607, ack 1, win 8576, options [nop,nop,TS val 1245062785 ecr =
949460787], length 1448
06:35:44.529611 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 1607:3055, ack 1, win 8576, options [nop,nop,TS val 1245062785 ecr =
949460787], length 1448
06:35:44.529626 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 3055, win 63764, options [nop,nop,TS val 949460788 ecr 1245062785], =
length 0
06:35:44.532250 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 3055:4503, ack 1, win 8576, options [nop,nop,TS val 1245062785 ecr =
949460787], length 1448
06:35:44.532316 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 4503, win 65215, options [nop,nop,TS val 949460788 ecr 1245062785], =
length 0
06:35:44.532864 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 4503:5951, ack 1, win 8576, options [nop,nop,TS val 1245062785 ecr =
949460787], length 1448
06:35:44.532881 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 5951, win 65111, options [nop,nop,TS val 949460788 ecr 1245062785], =
length 0
06:35:44.533276 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 5951:7399, ack 1, win 8576, options [nop,nop,TS val 1245062785 ecr =
949460787], length 1448
06:35:44.657465 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 7399:8847, ack 1, win 8576, options [nop,nop,TS val 1245062819 ecr =
949460788], length 1448
06:35:44.657625 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 8847, win 65160, options [nop,nop,TS val 949460789 ecr 1245062785], =
length 0
06:35:44.658344 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 8847:10295, ack 1, win 8576, options [nop,nop,TS val 1245062819 ecr =
949460788], length 1448
06:35:44.658778 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 10295:11743, ack 1, win 8576, options [nop,nop,TS val 1245062819 ecr =
949460788], length 1448
06:35:44.662915 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 11743:13191, ack 1, win 8576, options [nop,nop,TS val 1245062820 ecr =
949460788], length 1448
06:35:44.663994 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 13191:14639, ack 1, win 8576, options [nop,nop,TS val 1245062820 ecr =
949460788], length 1448
06:35:44.664489 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 14639:16087, ack 1, win 8576, options [nop,nop,TS val 1245062820 ecr =
949460788], length 1448
06:35:44.665123 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 16087:17535, ack 1, win 8576, options [nop,nop,TS val 1245062820 ecr =
949460788], length 1448
06:35:44.666432 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 17535, win 59369, options [nop,nop,TS val 949460789 ecr 1245062819], =
length 0
06:35:44.667877 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 17535, win 62279, options [nop,nop,TS val 949460789 ecr 1245062819], =
length 0
06:35:44.669224 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 17535, win 65192, options [nop,nop,TS val 949460789 ecr 1245062819], =
length 0
06:35:44.788593 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 17535:18983, ack 1, win 8576, options [nop,nop,TS val 1245062851 ecr =
949460789], length 1448
06:35:44.789474 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 18983:20431, ack 1, win 8576, options [nop,nop,TS val 1245062851 ecr =
949460789], length 1448
06:35:44.789530 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 20431, win 65199, options [nop,nop,TS val 949460790 ecr 1245062851], =
length 0
06:35:44.790069 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 20431:21879, ack 1, win 8576, options [nop,nop,TS val 1245062851 ecr =
949460789], length 1448
06:35:44.790084 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 21879, win 64862, options [nop,nop,TS val 949460790 ecr 1245062851], =
length 0
06:35:44.790480 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 21879:23327, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.790953 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 23327:24775, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.791388 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 24775:26223, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.791486 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 26223, win 63432, options [nop,nop,TS val 949460790 ecr 1245062853], =
length 0
06:35:44.791781 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 26223:27671, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.793199 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 27671, win 64881, options [nop,nop,TS val 949460791 ecr 1245062853], =
length 0
06:35:44.798922 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 27671:29119, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.799893 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 29119:30567, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.800443 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 30567, win 65171, options [nop,nop,TS val 949460791 ecr 1245062853], =
length 0
06:35:44.801280 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 30567:32015, ack 1, win 8576, options [nop,nop,TS val 1245062853 ecr =
949460789], length 1448
06:35:44.801295 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 32015, win 65160, options [nop,nop,TS val 949460791 ecr 1245062853], =
length 0
06:35:44.916107 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 32015:33463, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460790], length 1448
06:35:44.917017 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 33463:34911, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460790], length 1448
06:35:44.917061 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 34911, win 65167, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.918100 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 34911:36359, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460790], length 1448
06:35:44.918539 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 36359:37807, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460790], length 1448
06:35:44.918892 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 37807, win 65170, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.919609 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 37807:39255, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460790], length 1448
06:35:44.920004 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 39255:40703, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460791], length 1448
06:35:44.920456 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 40703, win 65171, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.920535 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 40703:42151, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460791], length 1448
06:35:44.921231 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 42151:43599, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460791], length 1448
06:35:44.921737 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 43599, win 65175, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.921823 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 43599:45047, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460791], length 1448
06:35:44.921839 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 45047, win 63930, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.922680 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 45047:46495, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460791], length 1448
06:35:44.923103 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 46495, win 65406, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.923115 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 46495:47943, ack 1, win 8576, options [nop,nop,TS val 1245062885 ecr =
949460791], length 1448
06:35:44.935222 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 47943:49391, ack 1, win 8576, options [nop,nop,TS val 1245062889 ecr =
949460791], length 1448
06:35:44.935407 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 49391, win 65423, options [nop,nop,TS val 949460792 ecr 1245062885], =
length 0
06:35:44.936416 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 49391:50839, ack 1, win 8576, options [nop,nop,TS val 1245062889 ecr =
949460791], length 1448
06:35:44.938310 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 50839:52287, ack 1, win 8576, options [nop,nop,TS val 1245062889 ecr =
949460791], length 1448
06:35:44.938488 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 52287, win 65427, options [nop,nop,TS val 949460792 ecr 1245062889], =
length 0
06:35:44.939992 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 52287:53735, ack 1, win 8576, options [nop,nop,TS val 1245062889 ecr =
949460791], length 1448
06:35:44.941124 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 53735:55183, ack 1, win 8576, options [nop,nop,TS val 1245062889 ecr =
949460791], length 1448
06:35:44.945309 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 55183, win 65430, options [nop,nop,TS val 949460792 ecr 1245062889], =
length 0
06:35:45.045394 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 55183:56631, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.045625 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 56631:58079, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.045649 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 58079, win 63840, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.046258 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 58079:59527, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.046931 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 59527:60975, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.047220 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 60975, win 63859, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.047422 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 60975:62423, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.048490 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 62423:63871, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.048641 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 63871, win 63868, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.049962 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 63871:65319, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.050151 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 65319, win 65332, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.050969 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 65319:66767, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.051897 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 66767:68215, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.053454 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 68215:69663, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.055186 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 69663:71111, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.055204 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 71111, win 60816, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.056110 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 71111:72559, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.056852 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 72559, win 62281, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.058091 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 72559:74007, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.058319 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 74007, win 63737, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.060442 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 74007:75455, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.061552 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 75455:76903, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.062658 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 76903:78351, ack 1, win 8576, options [nop,nop,TS val 1245062918 ecr =
949460792], length 1448
06:35:45.064183 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 78351, win 62306, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.065621 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 78351, win 65289, options [nop,nop,TS val 949460793 ecr 1245062918], =
length 0
06:35:45.082636 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 78351:79799, ack 1, win 8576, options [nop,nop,TS val 1245062921 ecr =
949460792], length 1448
06:35:45.083110 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 79799:81247, ack 1, win 8576, options [nop,nop,TS val 1245062921 ecr =
949460792], length 1448
06:35:45.083483 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 81247:82695, ack 1, win 8576, options [nop,nop,TS val 1245062921 ecr =
949460792], length 1448
06:35:45.084134 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 84143, win 62197, options [nop,nop,TS val 949460793 ecr 1245062921], =
length 0
06:35:45.085398 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 84143, win 65107, options [nop,nop,TS val 949460793 ecr 1245062921], =
length 0
06:35:45.086710 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 87039, win 65121, options [nop,nop,TS val 949460793 ecr 1245062921], =
length 0
06:35:45.091247 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 91383, win 63683, options [nop,nop,TS val 949460793 ecr 1245062923], =
length 0
06:35:45.205792 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 91383:92831, ack 1, win 8576, options [nop,nop,TS val 1245062954 ecr =
949460793], length 1448
06:35:45.206246 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 92831:94279, ack 1, win 8576, options [nop,nop,TS val 1245062954 ecr =
949460793], length 1448
06:35:45.206929 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 94279:95727, ack 1, win 8576, options [nop,nop,TS val 1245062954 ecr =
949460793], length 1448
06:35:45.207432 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 95727:97175, ack 1, win 8576, options [nop,nop,TS val 1245062954 ecr =
949460793], length 1448
06:35:45.207447 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 97175, win 60816, options [nop,nop,TS val 949460795 ecr 1245062954], =
length 0
06:35:45.208038 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 97175:98623, ack 1, win 8576, options [nop,nop,TS val 1245062954 ecr =
949460793], length 1448
06:35:45.208847 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 98623:100071, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.209028 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 100071, win 60820, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.210038 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 100071:101519, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.210585 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 101519, win 62280, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.211325 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 101519:102967, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.211818 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 102967:104415, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.211909 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 104415, win 62288, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.212472 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 104415:105863, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.212990 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 105863:107311, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.213288 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 107311, win 62299, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.214727 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 107311, win 65197, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.215462 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 107311:108759, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.216615 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 108759:110207, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.216629 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 110207, win 65160, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.217146 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 110207:111655, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.217843 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 111655:113103, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.218273 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 113103:114551, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.219093 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 114551:115999, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.222784 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 115999:117447, ack 1, win 8576, options [nop,nop,TS val 1245062954 =
ecr 949460793], length 1448
06:35:45.222868 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 117447, win 60817, options [nop,nop,TS val 949460795 ecr =
1245062954], length 0
06:35:45.223591 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 117447:118895, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.223606 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 118895, win 60536, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.224315 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 118895:120343, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.224940 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 120343:121791, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.225028 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 121791, win 60541, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.225599 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 121791:123239, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.226851 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 123239, win 62005, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.227174 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 123239:124687, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.228248 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 124687, win 63454, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.228517 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 124687:126135, ack 1, win 8576, options [nop,nop,TS val 1245062955 =
ecr 949460793], length 1448
06:35:45.229176 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 126135:127583, ack 1, win 8576, options [nop,nop,TS val 1245062958 =
ecr 949460793], length 1448
06:35:45.229748 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 127583:129031, ack 1, win 8576, options [nop,nop,TS val 1245062958 =
ecr 949460793], length 1448
06:35:45.229779 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 129031, win 62007, options [nop,nop,TS val 949460795 ecr =
1245062955], length 0
06:35:45.230383 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 129031:130479, ack 1, win 8576, options [nop,nop,TS val 1245062958 =
ecr 949460793], length 1448
06:35:45.230776 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 130479:131927, ack 1, win 8576, options [nop,nop,TS val 1245062958 =
ecr 949460793], length 1448
06:35:45.230789 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 131927, win 61222, options [nop,nop,TS val 949460795 ecr =
1245062958], length 0
06:35:45.231147 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 131927:133375, ack 1, win 8576, options [nop,nop,TS val 1245062958 =
ecr 949460793], length 1448
06:35:45.231521 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 133375:134823, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.231995 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 134823:136271, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.232158 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 136271, win 59776, options [nop,nop,TS val 949460795 ecr =
1245062958], length 0
06:35:45.233565 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 136271, win 62682, options [nop,nop,TS val 949460795 ecr =
1245062958], length 0
06:35:45.234837 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 136271:137719, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.234923 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 137719, win 64132, options [nop,nop,TS val 949460795 ecr =
1245062959], length 0
06:35:45.235451 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 137719:139167, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.236429 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 139167:140615, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.236447 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 140615, win 64686, options [nop,nop,TS val 949460795 ecr =
1245062959], length 0
06:35:45.236841 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 140615:142063, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.240748 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 142063:143511, ack 1, win 8576, options [nop,nop,TS val 1245062959 =
ecr 949460793], length 1448
06:35:45.240800 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 143511, win 65169, options [nop,nop,TS val 949460795 ecr =
1245062959], length 0
06:35:45.329167 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 143511:144959, ack 1, win 8576, options [nop,nop,TS val 1245062988 =
ecr 949460795], length 1448
06:35:45.329218 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 144959, win 65160, options [nop,nop,TS val 949460796 ecr =
1245062988], length 0
06:35:45.330467 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 144959:146407, ack 1, win 8576, options [nop,nop,TS val 1245062988 =
ecr 949460795], length 1448
06:35:45.331075 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 146407:147855, ack 1, win 8576, options [nop,nop,TS val 1245062988 =
ecr 949460795], length 1448
06:35:45.331197 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 147855, win 65161, options [nop,nop,TS val 949460796 ecr =
1245062988], length 0
06:35:45.331560 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 147855:149303, ack 1, win 8576, options [nop,nop,TS val 1245062988 =
ecr 949460795], length 1448
06:35:45.332298 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 149303:150751, ack 1, win 8576, options [nop,nop,TS val 1245062988 =
ecr 949460795], length 1448
06:35:45.332442 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 150751, win 65175, options [nop,nop,TS val 949460796 ecr =
1245062988], length 0
06:35:45.332688 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 150751:152199, ack 1, win 8576, options [nop,nop,TS val 1245062989 =
ecr 949460795], length 1448
06:35:45.333427 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 152199:153647, ack 1, win 8576, options [nop,nop,TS val 1245062989 =
ecr 949460795], length 1448
06:35:45.333667 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 153647, win 65177, options [nop,nop,TS val 949460796 ecr =
1245062989], length 0
06:35:45.333976 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 153647:155095, ack 1, win 8576, options [nop,nop,TS val 1245062989 =
ecr 949460795], length 1448
06:35:45.334534 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 155095:156543, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.334910 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 156543, win 65189, options [nop,nop,TS val 949460796 ecr =
1245062989], length 0
06:35:45.334913 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 156543:157991, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.334933 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 157991, win 63765, options [nop,nop,TS val 949460796 ecr =
1245062990], length 0
06:35:45.336536 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 157991:159439, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.336694 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 159439, win 65214, options [nop,nop,TS val 949460796 ecr =
1245062990], length 0
06:35:45.337056 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 159439:160887, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.337434 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 160887:162335, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.337965 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 162335, win 65214, options [nop,nop,TS val 949460796 ecr =
1245062990], length 0
06:35:45.339510 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 162335:163783, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.339991 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 163783:165231, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.340346 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 165231, win 65214, options [nop,nop,TS val 949460796 ecr =
1245062990], length 0
06:35:45.340457 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 165231:166679, ack 1, win 8576, options [nop,nop,TS val 1245062990 =
ecr 949460795], length 1448
06:35:45.341075 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 166679:168127, ack 1, win 8576, options [nop,nop,TS val 1245062991 =
ecr 949460795], length 1448
06:35:45.341575 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 168127, win 65222, options [nop,nop,TS val 949460796 ecr =
1245062990], length 0
06:35:45.341707 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 168127:169575, ack 1, win 8576, options [nop,nop,TS val 1245062991 =
ecr 949460795], length 1448
06:35:45.342264 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 169575:171023, ack 1, win 8576, options [nop,nop,TS val 1245062991 =
ecr 949460795], length 1448
06:35:45.342277 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 171023, win 63918, options [nop,nop,TS val 949460796 ecr =
1245062991], length 0
06:35:45.343797 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 171023:172471, ack 1, win 8576, options [nop,nop,TS val 1245062992 =
ecr 949460795], length 1448
06:35:45.344001 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 172471, win 65383, options [nop,nop,TS val 949460796 ecr =
1245062992], length 0
06:35:45.344838 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 172471:173919, ack 1, win 8576, options [nop,nop,TS val 1245062992 =
ecr 949460795], length 1448
06:35:45.345441 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 173919:175367, ack 1, win 8576, options [nop,nop,TS val 1245062992 =
ecr 949460795], length 1448
06:35:45.345658 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 175367, win 65391, options [nop,nop,TS val 949460796 ecr =
1245062992], length 0
06:35:45.346740 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 175367:176815, ack 1, win 8576, options [nop,nop,TS val 1245062992 =
ecr 949460795], length 1448
06:35:45.347990 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 176815:178263, ack 1, win 8576, options [nop,nop,TS val 1245062992 =
ecr 949460795], length 1448
06:35:45.348168 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 178263, win 65398, options [nop,nop,TS val 949460796 ecr =
1245062992], length 0
06:35:45.348480 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 178263:179711, ack 1, win 8576, options [nop,nop,TS val 1245062993 =
ecr 949460795], length 1448
06:35:45.349039 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 179711:181159, ack 1, win 8576, options [nop,nop,TS val 1245062993 =
ecr 949460795], length 1448
06:35:45.349403 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 181159, win 65399, options [nop,nop,TS val 949460796 ecr =
1245062993], length 0
06:35:45.349627 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 181159:182607, ack 1, win 8576, options [nop,nop,TS val 1245062993 =
ecr 949460795], length 1448
06:35:45.349641 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 182607, win 64457, options [nop,nop,TS val 949460796 ecr =
1245062993], length 0
06:35:45.350368 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 182607:184055, ack 1, win 8576, options [nop,nop,TS val 1245062993 =
ecr 949460795], length 1448
06:35:45.350861 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 184055:185503, ack 1, win 8576, options [nop,nop,TS val 1245062993 =
ecr 949460795], length 1448
06:35:45.350877 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 185503, win 64468, options [nop,nop,TS val 949460796 ecr =
1245062993], length 0
06:35:45.351475 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 185503:186951, ack 1, win 8576, options [nop,nop,TS val 1245062993 =
ecr 949460795], length 1448
06:35:45.356750 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 186951:188399, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.356927 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 188399, win 65163, options [nop,nop,TS val 949460796 ecr =
1245062993], length 0
06:35:45.357494 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 188399:189847, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.358307 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 189847:191295, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.358377 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 191295, win 65165, options [nop,nop,TS val 949460796 ecr =
1245062995], length 0
06:35:45.358877 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 191295:192743, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.359310 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 192743:194191, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.359618 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 194191, win 65176, options [nop,nop,TS val 949460796 ecr =
1245062995], length 0
06:35:45.360356 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 194191:195639, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.360392 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 195639, win 65160, options [nop,nop,TS val 949460796 ecr =
1245062995], length 0
06:35:45.361991 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 195639:197087, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.362450 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 197087:198535, ack 1, win 8576, options [nop,nop,TS val 1245062995 =
ecr 949460795], length 1448
06:35:45.362718 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 198535, win 65160, options [nop,nop,TS val 949460796 ecr =
1245062995], length 0
06:35:45.363036 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 198535:199983, ack 1, win 8576, options [nop,nop,TS val 1245062997 =
ecr 949460795], length 1448
06:35:45.363716 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 199983:201431, ack 1, win 8576, options [nop,nop,TS val 1245062997 =
ecr 949460795], length 1448
06:35:45.363978 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 201431, win 65174, options [nop,nop,TS val 949460796 ecr =
1245062997], length 0
06:35:45.364344 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 201431:202879, ack 1, win 8576, options [nop,nop,TS val 1245062997 =
ecr 949460795], length 1448
06:35:45.365003 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 202879:204327, ack 1, win 8576, options [nop,nop,TS val 1245062997 =
ecr 949460795], length 1448
06:35:45.365228 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 204327, win 65194, options [nop,nop,TS val 949460796 ecr =
1245062997], length 0
06:35:45.454594 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 204327:205775, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.454643 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 205775, win 65160, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.455231 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 205775:207223, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.455901 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 207223:208671, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.455916 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 208671, win 64684, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.456634 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 208671:210119, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.457127 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 210119:211567, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.457141 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 211567, win 64244, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.457785 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 211567:213015, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.458176 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 213015:214463, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.458191 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 214463, win 63577, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.458951 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 214463:215911, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.459342 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 215911:217359, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.459429 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 217359, win 63586, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.460575 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 217359:218807, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.460727 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 218807, win 65035, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.460946 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 218807:220255, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.461688 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 220255:221703, ack 1, win 8576, options [nop,nop,TS val 1245063020 =
ecr 949460796], length 1448
06:35:45.462015 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 221703, win 65055, options [nop,nop,TS val 949460797 ecr =
1245063020], length 0
06:35:45.462183 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 221703:223151, ack 1, win 8576, options [nop,nop,TS val 1245063021 =
ecr 949460796], length 1448
06:35:45.462676 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 223151:224599, ack 1, win 8576, options [nop,nop,TS val 1245063021 =
ecr 949460796], length 1448
06:35:45.463301 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 224599, win 65059, options [nop,nop,TS val 949460797 ecr =
1245063021], length 0
06:35:45.464075 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 224599:226047, ack 1, win 8576, options [nop,nop,TS val 1245063021 =
ecr 949460796], length 1448
06:35:45.464711 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 226047:227495, ack 1, win 8576, options [nop,nop,TS val 1245063021 =
ecr 949460796], length 1448
06:35:45.464724 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 227495, win 65025, options [nop,nop,TS val 949460797 ecr =
1245063021], length 0
06:35:45.465262 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 227495:228943, ack 1, win 8576, options [nop,nop,TS val 1245063022 =
ecr 949460796], length 1448
06:35:45.465677 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 228943:230391, ack 1, win 8576, options [nop,nop,TS val 1245063022 =
ecr 949460796], length 1448
06:35:45.466043 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 230391, win 65027, options [nop,nop,TS val 949460797 ecr =
1245063022], length 0
06:35:45.466288 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 230391:231839, ack 1, win 8576, options [nop,nop,TS val 1245063022 =
ecr 949460796], length 1448
06:35:45.467105 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 231839:233287, ack 1, win 8576, options [nop,nop,TS val 1245063022 =
ecr 949460796], length 1448
06:35:45.467324 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 233287, win 65045, options [nop,nop,TS val 949460797 ecr =
1245063022], length 0
06:35:45.467598 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
seq 233287:234735, ack 1, win 8576, options [nop,nop,TS val 1245063023 =
ecr 949460796], length 1448
06:35:45.468038 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 234735:234766, ack 1, win 8576, options [nop,nop,TS val 1245063023 =
ecr 949460796], length 31
06:35:45.468051 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [.], =
ack 234766, win 65189, options [nop,nop,TS val 949460797 ecr =
1245063023], length 0
06:35:47.021712 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [P.], =
seq 1:24, ack 234766, win 65535, options [nop,nop,TS val 949460813 ecr =
1245063023], length 23
06:35:47.021730 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 234766, win 65535, options [nop,nop,TS val 949460813 ecr =
1245063023], length 0
06:35:47.150824 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
ack 24, win 8576, options [nop,nop,TS val 1245063442 ecr 949460813], =
length 0
06:35:47.150839 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 234766, win 65535, options [nop,nop,TS val 949460814 ecr =
1245063442], length 0
06:35:47.151411 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [P.], =
seq 234766:234789, ack 25, win 8576, options [nop,nop,TS val 1245063442 =
ecr 949460813], length 23
06:35:47.151428 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [R], =
seq 2152838220, win 0, length 0
06:35:47.151788 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [F.], =
seq 234789, ack 25, win 8576, options [nop,nop,TS val 1245063442 ecr =
949460813], length 0
06:35:47.151801 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [R], =
seq 2152838220, win 0, length 0
06:35:47.154136 IP mail.ietf.org.https > 10.71.5.180.60356: Flags [.], =
ack 25, win 8576, length 0
06:35:47.154158 IP 10.71.5.180.60356 > mail.ietf.org.https: Flags [R], =
seq 2152838220, win 0, length 0

--Apple-Mail-105-709146384
Content-Disposition: attachment;
	filename=10.71.5.180.60355.txt
Content-Type: text/plain;
	name="10.71.5.180.60355.txt"
Content-Transfer-Encoding: quoted-printable

06:35:40.836048 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 3580034756:3580034835, ack 1910942697, win 8576, options [nop,nop,TS =
val 1245061862 ecr 949460744], length 79
06:35:40.836100 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 79:159, ack 1, win 8576, options [nop,nop,TS val 1245061862 ecr =
949460744], length 80
06:35:40.836126 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460751 ecr =
1245061739,nop,nop,sack 1 {0:79}], length 0
06:35:40.836169 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460751 ecr =
1245061739,nop,nop,sack 1 {0:159}], length 0
06:35:40.837228 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 4294966734:0, ack 1, win 8576, options [nop,nop,TS val 1245061862 =
ecr 949460744], length 562
06:35:40.837308 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 159, win 65535, options [nop,nop,TS val 949460751 ecr 1245061862], =
length 0
06:35:40.968091 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 159:1607, ack 1, win 8576, options [nop,nop,TS val 1245061895 ecr =
949460751], length 1448
06:35:40.968362 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 1607:3055, ack 1, win 8576, options [nop,nop,TS val 1245061895 ecr =
949460751], length 1448
06:35:40.968418 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 3055, win 63769, options [nop,nop,TS val 949460752 ecr 1245061895], =
length 0
06:35:40.968711 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 3055:4503, ack 1, win 8576, options [nop,nop,TS val 1245061895 ecr =
949460751], length 1448
06:35:40.969282 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 4503:5951, ack 1, win 8576, options [nop,nop,TS val 1245061895 ecr =
949460751], length 1448
06:35:40.969314 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 5951, win 61951, options [nop,nop,TS val 949460752 ecr 1245061895], =
length 0
06:35:40.971063 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 5951, win 64854, options [nop,nop,TS val 949460752 ecr 1245061895], =
length 0
06:35:41.100462 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 5951:7399, ack 1, win 8576, options [nop,nop,TS val 1245061928 ecr =
949460752], length 1448
06:35:41.100577 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 7399:8847, ack 1, win 8576, options [nop,nop,TS val 1245061928 ecr =
949460752], length 1448
06:35:41.100606 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 8847, win 63712, options [nop,nop,TS val 949460754 ecr 1245061928], =
length 0
06:35:41.101215 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 8847:10295, ack 1, win 8576, options [nop,nop,TS val 1245061928 ecr =
949460752], length 1448
06:35:41.101790 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 10295:11743, ack 1, win 8576, options [nop,nop,TS val 1245061928 ecr =
949460752], length 1448
06:35:41.102285 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 11743:13191, ack 1, win 8576, options [nop,nop,TS val 1245061928 ecr =
949460752], length 1448
06:35:41.102363 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 13191, win 62286, options [nop,nop,TS val 949460754 ecr 1245061928], =
length 0
06:35:41.102958 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 13191:14639, ack 1, win 8576, options [nop,nop,TS val 1245061928 ecr =
949460752], length 1448
06:35:41.104089 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 14639, win 63734, options [nop,nop,TS val 949460754 ecr 1245061928], =
length 0
06:35:41.232382 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 14639:16087, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.232630 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 16087, win 65191, options [nop,nop,TS val 949460755 ecr 1245061961], =
length 0
06:35:41.232792 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 16087:17535, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.233166 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 17535:18983, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.233940 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 18983:20431, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.234414 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 20431:21879, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.234438 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 21879, win 61801, options [nop,nop,TS val 949460755 ecr 1245061961], =
length 0
06:35:41.235065 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 21879:23327, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.235479 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 23327:24775, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.236115 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 24775, win 61812, options [nop,nop,TS val 949460755 ecr 1245061961], =
length 0
06:35:41.236149 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 24775:26223, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.237506 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 26223:27671, ack 1, win 8576, options [nop,nop,TS val 1245061961 ecr =
949460754], length 1448
06:35:41.237878 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 27671, win 61834, options [nop,nop,TS val 949460755 ecr 1245061961], =
length 0
06:35:41.239566 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 27671, win 64734, options [nop,nop,TS val 949460755 ecr 1245061961], =
length 0
06:35:41.368413 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 27671:29119, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.368569 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 29119:30567, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.369549 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 30567, win 64736, options [nop,nop,TS val 949460756 ecr 1245061994], =
length 0
06:35:41.370513 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 30567:32015, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.370933 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 32015:33463, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.371503 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 33463, win 64736, options [nop,nop,TS val 949460756 ecr 1245061994], =
length 0
06:35:41.371573 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 33463:34911, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.371592 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 34911, win 63339, options [nop,nop,TS val 949460756 ecr 1245061994], =
length 0
06:35:41.373005 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 34911:36359, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.373426 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 36359, win 64796, options [nop,nop,TS val 949460756 ecr 1245061994], =
length 0
06:35:41.373575 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 36359:37807, ack 1, win 8576, options [nop,nop,TS val 1245061994 ecr =
949460755], length 1448
06:35:41.374600 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 37807:39255, ack 1, win 8576, options [nop,nop,TS val 1245061995 ecr =
949460755], length 1448
06:35:41.375254 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 39255:40703, ack 1, win 8576, options [nop,nop,TS val 1245061995 ecr =
949460755], length 1448
06:35:41.375320 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 40703, win 63368, options [nop,nop,TS val 949460756 ecr 1245061994], =
length 0
06:35:41.375648 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 40703:42151, ack 1, win 8576, options [nop,nop,TS val 1245061995 ecr =
949460755], length 1448
06:35:41.376306 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 42151:43599, ack 1, win 8576, options [nop,nop,TS val 1245061995 ecr =
949460755], length 1448
06:35:41.376862 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 43599:45047, ack 1, win 8576, options [nop,nop,TS val 1245061995 ecr =
949460755], length 1448
06:35:41.377070 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 45047, win 61923, options [nop,nop,TS val 949460756 ecr 1245061995], =
length 0
06:35:41.378059 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 45047:46495, ack 1, win 8576, options [nop,nop,TS val 1245061995 ecr =
949460755], length 1448
06:35:41.378636 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 46495, win 63386, options [nop,nop,TS val 949460756 ecr 1245061995], =
length 0
06:35:41.502427 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 47943, win 65160, options [nop,nop,TS val 949460758 ecr 1245062029], =
length 0
06:35:41.504110 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 50839, win 65177, options [nop,nop,TS val 949460758 ecr 1245062029], =
length 0
06:35:41.505551 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 55183, win 63733, options [nop,nop,TS val 949460758 ecr 1245062029], =
length 0
06:35:41.507330 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 59527, win 62291, options [nop,nop,TS val 949460758 ecr 1245062029], =
length 0
06:35:41.508137 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 60975, win 62500, options [nop,nop,TS val 949460758 ecr 1245062029], =
length 0
06:35:41.509632 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 63871, win 62515, options [nop,nop,TS val 949460758 ecr 1245062030], =
length 0
06:35:41.796233 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 127583:129031, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.796303 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 129031, win 65160, options [nop,nop,TS val 949460761 ecr =
1245062095], length 0
06:35:41.796420 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 129031:130479, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.797252 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 130479:131927, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.797266 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 131927, win 63862, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.797826 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 131927:133375, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.798242 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 133375:134823, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.798256 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 134823, win 62991, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.798691 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 134823:136271, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.799624 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 136271, win 64446, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.802445 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 136271:137719, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.802466 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 137719, win 65160, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.803041 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 137719:139167, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.803694 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 139167:140615, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.803902 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 140615, win 65166, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.804449 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 140615:142063, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.804842 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 142063:143511, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.805311 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 143511, win 65190, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.805354 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 143511:144959, ack 1, win 8576, options [nop,nop,TS val 1245062102 =
ecr 949460759], length 1448
06:35:41.806774 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 144959:146407, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.806835 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 146407, win 65190, options [nop,nop,TS val 949460761 ecr =
1245062102], length 0
06:35:41.807755 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 146407:147855, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.808265 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 147855:149303, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.808476 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 149303, win 65194, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.808654 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 149303:150751, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.808667 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 150751, win 64080, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.809391 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 150751:152199, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.809765 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 152199:153647, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.810066 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 153647, win 64083, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.810156 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 153647:155095, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.810833 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 155095:156543, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.811467 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 156543, win 64087, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.812209 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 156543:157991, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.812725 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 157991:159439, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.812869 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 159439, win 64104, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.813133 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 159439:160887, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.813950 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 160887:162335, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.814271 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 162335, win 64114, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.814363 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 162335:163783, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.814376 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 163783, win 62799, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.815219 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 163783:165231, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.815729 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 165231, win 64257, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.816761 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 165231:166679, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.817193 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 166679:168127, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.817222 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 168127, win 64528, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.817865 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 168127:169575, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.818426 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 169575:171023, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.818619 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 171023, win 64531, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.818809 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 171023:172471, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.819409 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 172471:173919, ack 1, win 8576, options [nop,nop,TS val 1245062103 =
ecr 949460759], length 1448
06:35:41.819881 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 173919:175367, ack 1, win 8576, options [nop,nop,TS val 1245062104 =
ecr 949460759], length 1448
06:35:41.819982 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 175367, win 63087, options [nop,nop,TS val 949460761 ecr =
1245062103], length 0
06:35:41.821605 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 175367:176815, ack 1, win 8576, options [nop,nop,TS val 1245062104 =
ecr 949460759], length 1448
06:35:41.821624 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 176815, win 65160, options [nop,nop,TS val 949460761 ecr =
1245062104], length 0
06:35:41.822074 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 176815:177757, ack 1, win 8576, options [nop,nop,TS val 1245062104 =
ecr 949460759], length 942
06:35:41.822087 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 177757, win 65063, options [nop,nop,TS val 949460761 ecr =
1245062104], length 0
06:35:41.822909 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [P.], =
seq 1:430, ack 177757, win 65535, options [nop,nop,TS val 949460761 ecr =
1245062104], length 429
06:35:41.963838 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
ack 430, win 9648, options [nop,nop,TS val 1245062144 ecr 949460761], =
length 0
06:35:43.671328 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 177757:178318, ack 430, win 9648, options [nop,nop,TS val 1245062571 =
ecr 949460761], length 561
06:35:43.671411 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 178318, win 65535, options [nop,nop,TS val 949460779 ecr =
1245062571], length 0
06:35:43.671539 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 178318:178397, ack 430, win 9648, options [nop,nop,TS val 1245062571 =
ecr 949460761], length 79
06:35:43.671651 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 178397, win 65535, options [nop,nop,TS val 949460779 ecr =
1245062571], length 0
06:35:43.672214 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 178397:178477, ack 430, win 9648, options [nop,nop,TS val 1245062571 =
ecr 949460761], length 80
06:35:43.672252 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 178477, win 65535, options [nop,nop,TS val 949460779 ecr =
1245062571], length 0
06:35:43.805139 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 178477:179925, ack 430, win 9648, options [nop,nop,TS val 1245062603 =
ecr 949460779], length 1448
06:35:43.805384 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 179925:181373, ack 430, win 9648, options [nop,nop,TS val 1245062603 =
ecr 949460779], length 1448
06:35:43.805429 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 181373, win 63787, options [nop,nop,TS val 949460781 ecr =
1245062603], length 0
06:35:43.805801 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 181373:182821, ack 430, win 9648, options [nop,nop,TS val 1245062603 =
ecr 949460779], length 1448
06:35:43.806543 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 182821:184269, ack 430, win 9648, options [nop,nop,TS val 1245062603 =
ecr 949460779], length 1448
06:35:43.806566 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 184269, win 63112, options [nop,nop,TS val 949460781 ecr =
1245062603], length 0
06:35:43.807326 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 184269:185717, ack 430, win 9648, options [nop,nop,TS val 1245062604 =
ecr 949460779], length 1448
06:35:43.807802 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 185717:187165, ack 430, win 9648, options [nop,nop,TS val 1245062604 =
ecr 949460779], length 1448
06:35:43.807818 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 187165, win 62604, options [nop,nop,TS val 949460781 ecr =
1245062604], length 0
06:35:43.809142 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 187165, win 65519, options [nop,nop,TS val 949460781 ecr =
1245062604], length 0
06:35:43.937424 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 187165:188613, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.937741 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 188613:190061, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.938172 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 190061:191509, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.938547 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 191509:192957, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.939004 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 192957, win 62626, options [nop,nop,TS val 949460782 ecr =
1245062637], length 0
06:35:43.939780 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 192957:194405, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.940253 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 194405:195853, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.940864 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 195853:197301, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.941133 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 197301, win 61184, options [nop,nop,TS val 949460782 ecr =
1245062637], length 0
06:35:43.941272 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 197301:198749, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.942054 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 198749:200197, ack 430, win 9648, options [nop,nop,TS val 1245062637 =
ecr 949460781], length 1448
06:35:43.942072 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 200197, win 59646, options [nop,nop,TS val 949460782 ecr =
1245062637], length 0
06:35:43.944295 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 200197, win 62543, options [nop,nop,TS val 949460782 ecr =
1245062637], length 0
06:35:43.946162 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 200197, win 65452, options [nop,nop,TS val 949460782 ecr =
1245062637], length 0
06:35:44.072812 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 200197:201645, ack 430, win 9648, options [nop,nop,TS val 1245062670 =
ecr 949460782], length 1448
06:35:44.073274 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 201645:203093, ack 430, win 9648, options [nop,nop,TS val 1245062670 =
ecr 949460782], length 1448
06:35:44.073792 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 203093, win 65469, options [nop,nop,TS val 949460783 ecr =
1245062670], length 0
06:35:44.073904 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 203093:204541, ack 430, win 9648, options [nop,nop,TS val 1245062670 =
ecr 949460782], length 1448
06:35:44.074278 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 204541:205989, ack 430, win 9648, options [nop,nop,TS val 1245062670 =
ecr 949460782], length 1448
06:35:44.074935 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 205989:207437, ack 430, win 9648, options [nop,nop,TS val 1245062670 =
ecr 949460782], length 1448
06:35:44.075353 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 207437:208885, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.075399 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 208885, win 62573, options [nop,nop,TS val 949460783 ecr =
1245062670], length 0
06:35:44.076202 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 208885:210333, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.076795 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 210333:211781, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.076812 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 210333, win 64037, options [nop,nop,TS val 949460783 ecr =
1245062671], length 0
06:35:44.077370 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 211781:213229, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.077384 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 213229, win 62265, options [nop,nop,TS val 949460783 ecr =
1245062671], length 0
06:35:44.077882 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 213229:214677, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.078498 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 214677:216125, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.078887 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 216125, win 62283, options [nop,nop,TS val 949460783 ecr =
1245062671], length 0
06:35:44.080297 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 216125, win 65196, options [nop,nop,TS val 949460783 ecr =
1245062671], length 0
06:35:44.082806 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 216125:217573, ack 430, win 9648, options [nop,nop,TS val 1245062671 =
ecr 949460782], length 1448
06:35:44.091062 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 217573, win 65535, options [nop,nop,TS val 949460783 ecr =
1245062671], length 0
06:35:44.208382 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 217573:219021, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.208912 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 219021:220469, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.209338 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 220469, win 65535, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.210043 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 220469:221917, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.210686 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 221917:223365, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.210987 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 223365, win 65535, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.211293 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 223365:224813, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.212597 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 224813:226261, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.212793 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 226261, win 65535, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.213233 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 226261:227709, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.214692 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 227709:229157, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.214889 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 229157, win 65535, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.215165 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 229157:230605, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.215179 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 230605, win 64627, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.216504 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 230605:232053, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.217078 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 232053:233501, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.217110 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 233501, win 64850, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.217833 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 233501:234949, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.218386 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 234949:236397, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.218793 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 236397, win 64859, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.218939 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 236397:237845, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.220203 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 237845:239293, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.220398 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 239293, win 64862, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.221824 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 239293:240741, ack 430, win 9648, options [nop,nop,TS val 1245062705 =
ecr 949460783], length 1448
06:35:44.231309 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 240741:242189, ack 430, win 9648, options [nop,nop,TS val 1245062708 =
ecr 949460783], length 1448
06:35:44.231428 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 242189, win 65182, options [nop,nop,TS val 949460785 ecr =
1245062705], length 0
06:35:44.345905 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 242189:243637, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.345937 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 243637, win 65160, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.346624 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 243637:245085, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.347078 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 245085:246533, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.347335 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 246533, win 65178, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.347891 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 246533:247981, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.348468 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 247981:249429, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.348777 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 249429, win 65195, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.349038 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 249429:250877, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.349656 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 250877:252325, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.350278 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 252325, win 65206, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.350636 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 252325:253773, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.351008 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 253773:255221, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.351688 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 255221:256669, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.351702 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 256669, win 63568, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.352381 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 256669:258117, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.352974 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 258117:259565, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.353123 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 259565, win 63574, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.353672 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 259565:261013, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.354263 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 261013:262461, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.354505 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 262461, win 63575, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.354694 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 262461:263909, ack 430, win 9648, options [nop,nop,TS val 1245062739 =
ecr 949460785], length 1448
06:35:44.355252 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 263909:265357, ack 430, win 9648, options [nop,nop,TS val 1245062740 =
ecr 949460785], length 1448
06:35:44.355627 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 265357:266805, ack 430, win 9648, options [nop,nop,TS val 1245062740 =
ecr 949460785], length 1448
06:35:44.356119 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 266805:268253, ack 430, win 9648, options [nop,nop,TS val 1245062740 =
ecr 949460785], length 1448
06:35:44.356198 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 268253, win 60682, options [nop,nop,TS val 949460786 ecr =
1245062739], length 0
06:35:44.356570 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 268253:269701, ack 430, win 9648, options [nop,nop,TS val 1245062740 =
ecr 949460785], length 1448
06:35:44.356584 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 269701, win 60024, options [nop,nop,TS val 949460786 ecr =
1245062740], length 0
06:35:44.357429 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 269701:271149, ack 430, win 9648, options [nop,nop,TS val 1245062740 =
ecr 949460785], length 1448
06:35:44.357945 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 271149:272597, ack 430, win 9648, options [nop,nop,TS val 1245062740 =
ecr 949460785], length 1448
06:35:44.358022 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 272597, win 60027, options [nop,nop,TS val 949460786 ecr =
1245062740], length 0
06:35:44.358657 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 272597:274045, ack 430, win 9648, options [nop,nop,TS val 1245062741 =
ecr 949460785], length 1448
06:35:44.358670 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 274045, win 59854, options [nop,nop,TS val 949460786 ecr =
1245062741], length 0
06:35:44.360084 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 274045, win 62761, options [nop,nop,TS val 949460786 ecr =
1245062741], length 0
06:35:44.369285 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 274045:275493, ack 430, win 9648, options [nop,nop,TS val 1245062743 =
ecr 949460785], length 1448
06:35:44.369584 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 275493, win 65162, options [nop,nop,TS val 949460786 ecr =
1245062743], length 0
06:35:44.369840 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 275493:276941, ack 430, win 9648, options [nop,nop,TS val 1245062743 =
ecr 949460785], length 1448
06:35:44.370595 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 276941:278389, ack 430, win 9648, options [nop,nop,TS val 1245062743 =
ecr 949460785], length 1448
06:35:44.370995 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 278389, win 65167, options [nop,nop,TS val 949460786 ecr =
1245062743], length 0
06:35:44.371208 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 278389:279837, ack 430, win 9648, options [nop,nop,TS val 1245062743 =
ecr 949460785], length 1448
06:35:44.371581 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 279837:281285, ack 430, win 9648, options [nop,nop,TS val 1245062743 =
ecr 949460785], length 1448
06:35:44.372431 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 281285, win 65168, options [nop,nop,TS val 949460786 ecr =
1245062743], length 0
06:35:44.482139 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 281285:282733, ack 430, win 9648, options [nop,nop,TS val 1245062773 =
ecr 949460786], length 1448
06:35:44.482497 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 282733:284181, ack 430, win 9648, options [nop,nop,TS val 1245062773 =
ecr 949460786], length 1448
06:35:44.482879 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 284181, win 65178, options [nop,nop,TS val 949460787 ecr =
1245062773], length 0
06:35:44.487632 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 284181:285629, ack 430, win 9648, options [nop,nop,TS val 1245062773 =
ecr 949460786], length 1448
06:35:44.488596 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 285629:287077, ack 430, win 9648, options [nop,nop,TS val 1245062773 =
ecr 949460786], length 1448
06:35:44.488613 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 287077, win 65160, options [nop,nop,TS val 949460787 ecr =
1245062773], length 0
06:35:44.489401 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 287077:288525, ack 430, win 9648, options [nop,nop,TS val 1245062773 =
ecr 949460786], length 1448
06:35:44.491534 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 288525:289973, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.491572 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 289973, win 65162, options [nop,nop,TS val 949460787 ecr =
1245062773], length 0
06:35:44.492449 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 289973:291421, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.493004 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 291421:292869, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.493093 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 292869, win 65172, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.494765 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 292869:294317, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.495851 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 294317:295765, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.496177 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 295765, win 65174, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.496426 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 295765:297213, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.497313 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 297213:298661, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.497434 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 298661, win 65191, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.498372 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 298661:300109, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.498387 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 300109, win 65160, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.501631 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 300109:301557, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.502719 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 301557:303005, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.503004 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 303005, win 65178, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.503209 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 303005:304453, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.503787 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 304453:305901, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.504414 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 305901, win 65188, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.504421 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 305901:307349, ack 430, win 9648, options [nop,nop,TS val 1245062774 =
ecr 949460786], length 1448
06:35:44.505214 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 307349:308797, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.505669 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 308797:310245, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.505671 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 308797, win 65203, options [nop,nop,TS val 949460788 ecr =
1245062774], length 0
06:35:44.506846 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 310245:311693, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.506934 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 311693, win 65210, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.508412 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 311693:313141, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.508428 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 313141, win 65160, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.511601 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 313141:314589, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.513360 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 314589:316037, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.513401 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 316037, win 65161, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.514175 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 316037:317485, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.514893 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 317485:318933, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.515001 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 318933, win 65164, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.515591 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 318933:320381, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.516655 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 320381:321829, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.518089 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 321829:323277, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.518259 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 323277, win 63726, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.520526 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 323277:324725, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.520579 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 324725, win 65188, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.523508 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 324725:326173, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.523524 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 326173, win 65160, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.524534 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 326173:327621, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.524889 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 327621:329069, ack 430, win 9648, options [nop,nop,TS val 1245062775 =
ecr 949460786], length 1448
06:35:44.525251 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 329069, win 65175, options [nop,nop,TS val 949460788 ecr =
1245062775], length 0
06:35:44.525441 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 329069:330517, ack 430, win 9648, options [nop,nop,TS val 1245062779 =
ecr 949460786], length 1448
06:35:44.526217 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 330517:331965, ack 430, win 9648, options [nop,nop,TS val 1245062779 =
ecr 949460786], length 1448
06:35:44.526640 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 331965, win 65179, options [nop,nop,TS val 949460788 ecr =
1245062779], length 0
06:35:44.526788 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 331965:333413, ack 430, win 9648, options [nop,nop,TS val 1245062779 =
ecr 949460786], length 1448
06:35:44.528186 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 333413:334861, ack 430, win 9648, options [nop,nop,TS val 1245062779 =
ecr 949460786], length 1448
06:35:44.528236 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 334861, win 65186, options [nop,nop,TS val 949460788 ecr =
1245062779], length 0
06:35:44.528804 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 334861:336309, ack 430, win 9648, options [nop,nop,TS val 1245062779 =
ecr 949460786], length 1448
06:35:44.619183 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 336309:337757, ack 430, win 9648, options [nop,nop,TS val 1245062807 =
ecr 949460787], length 1448
06:35:44.619207 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 337757, win 65160, options [nop,nop,TS val 949460789 ecr =
1245062779], length 0
06:35:44.620812 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 337757:339205, ack 430, win 9648, options [nop,nop,TS val 1245062807 =
ecr 949460787], length 1448
06:35:44.622132 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 339205:340653, ack 430, win 9648, options [nop,nop,TS val 1245062807 =
ecr 949460787], length 1448
06:35:44.622148 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 340653, win 65160, options [nop,nop,TS val 949460789 ecr =
1245062807], length 0
06:35:44.626510 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 340653:342101, ack 430, win 9648, options [nop,nop,TS val 1245062807 =
ecr 949460787], length 1448
06:35:44.628641 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 342101:343549, ack 430, win 9648, options [nop,nop,TS val 1245062807 =
ecr 949460787], length 1448
06:35:44.628679 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 343549, win 65160, options [nop,nop,TS val 949460789 ecr =
1245062807], length 0
06:35:44.631180 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 343549:344997, ack 430, win 9648, options [nop,nop,TS val 1245062807 =
ecr 949460787], length 1448
06:35:44.631195 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 344997, win 65160, options [nop,nop,TS val 949460789 ecr =
1245062807], length 0
06:35:44.642347 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 344997:346445, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460787], length 1448
06:35:44.643437 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 346445:347893, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460787], length 1448
06:35:44.643774 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 347893, win 65174, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.644089 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 347893:349341, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460787], length 1448
06:35:44.644647 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 349341:350789, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460787], length 1448
06:35:44.645117 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 350789:352237, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460787], length 1448
06:35:44.645400 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 352237, win 63731, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.645772 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 352237:353685, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460787], length 1448
06:35:44.646547 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 353685:355133, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.646765 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 355133, win 63735, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.647019 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 355133:356581, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.647390 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 356581:358029, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.647404 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 358029, win 62073, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.648560 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 358029:359477, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.648992 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 359477, win 63545, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.649234 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 359477:360925, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.649608 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 360925:362373, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.650423 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 362373:363821, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.650568 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 363821, win 62101, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.650795 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 363821:365269, ack 430, win 9648, options [nop,nop,TS val 1245062811 =
ecr 949460788], length 1448
06:35:44.651510 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 365269:366717, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.651885 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 366717:368165, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.652008 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 368165, win 60653, options [nop,nop,TS val 949460789 ecr =
1245062811], length 0
06:35:44.652618 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 368165:369613, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.653055 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 369613:371061, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.653068 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 371061, win 59961, options [nop,nop,TS val 949460789 ecr =
1245062812], length 0
06:35:44.653650 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 371061:372509, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.654044 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 372509:373957, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.654356 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 373957, win 59967, options [nop,nop,TS val 949460789 ecr =
1245062812], length 0
06:35:44.654456 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 373957:375405, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.655132 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 375405:376853, ack 430, win 9648, options [nop,nop,TS val 1245062812 =
ecr 949460788], length 1448
06:35:44.655623 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 376853:378301, ack 430, win 9648, options [nop,nop,TS val 1245062814 =
ecr 949460788], length 1448
06:35:44.655776 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 378301, win 58521, options [nop,nop,TS val 949460789 ecr =
1245062812], length 0
06:35:44.656054 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 378301:379749, ack 430, win 9648, options [nop,nop,TS val 1245062814 =
ecr 949460788], length 1448
06:35:44.656794 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 379749:381197, ack 430, win 9648, options [nop,nop,TS val 1245062814 =
ecr 949460788], length 1448
06:35:44.657186 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 381197, win 58533, options [nop,nop,TS val 949460789 ecr =
1245062814], length 0
06:35:44.659083 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 381197, win 61433, options [nop,nop,TS val 949460789 ecr =
1245062814], length 0
06:35:44.659368 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 381197:382645, ack 430, win 9648, options [nop,nop,TS val 1245062816 =
ecr 949460788], length 1448
06:35:44.659984 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 382645:384093, ack 430, win 9648, options [nop,nop,TS val 1245062816 =
ecr 949460788], length 1448
06:35:44.659997 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 384093, win 60361, options [nop,nop,TS val 949460789 ecr =
1245062816], length 0
06:35:44.660941 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 384093:385541, ack 430, win 9648, options [nop,nop,TS val 1245062816 =
ecr 949460788], length 1448
06:35:44.661394 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 385541, win 61810, options [nop,nop,TS val 949460789 ecr =
1245062816], length 0
06:35:44.661610 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
seq 385541:386989, ack 430, win 9648, options [nop,nop,TS val 1245062816 =
ecr 949460788], length 1448
06:35:44.662841 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 386989, win 63258, options [nop,nop,TS val 949460789 ecr =
1245062816], length 0
06:35:44.663345 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 386989:387536, ack 430, win 9648, options [nop,nop,TS val 1245062816 =
ecr 949460788], length 547
06:35:44.663358 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [.], =
ack 387536, win 63463, options [nop,nop,TS val 949460789 ecr =
1245062816], length 0
06:35:46.072081 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [P.], =
seq 430:453, ack 387536, win 65535, options [nop,nop,TS val 949460803 =
ecr 1245062816], length 23
06:35:46.072152 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [F.], =
seq 453, ack 387536, win 65535, options [nop,nop,TS val 949460803 ecr =
1245062816], length 0
06:35:46.210235 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
ack 453, win 9648, options [nop,nop,TS val 1245063204 ecr 949460803], =
length 0
06:35:46.210352 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [F.], =
seq 453, ack 387536, win 65535, options [nop,nop,TS val 949460805 ecr =
1245063204], length 0
06:35:46.210750 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [P.], =
seq 387536:387559, ack 454, win 9648, options [nop,nop,TS val 1245063204 =
ecr 949460803], length 23
06:35:46.210832 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [R], =
seq 1910943150, win 0, length 0
06:35:46.211381 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [F.], =
seq 387559, ack 454, win 9648, options [nop,nop,TS val 1245063204 ecr =
949460803], length 0
06:35:46.211450 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [R], =
seq 1910943150, win 0, length 0
06:35:46.212818 IP mail.ietf.org.https > 10.71.5.180.60355: Flags [.], =
ack 454, win 9648, length 0
06:35:46.212889 IP 10.71.5.180.60355 > mail.ietf.org.https: Flags [R], =
seq 1910943150, win 0, length 0

--Apple-Mail-105-709146384
Content-Disposition: attachment;
	filename=10.71.5.180.60354.txt
Content-Type: text/plain;
	name="10.71.5.180.60354.txt"
Content-Transfer-Encoding: quoted-printable

06:35:44.002375 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 3407461415:3407461494, ack 680741256, win 8576, options [nop,nop,TS =
val 1245062659 ecr 949460744], length 79
06:35:44.002459 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460783 ecr =
1245061739,nop,nop,sack 1 {0:79}], length 0
06:35:44.003536 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 4294966734:0, ack 1, win 8576, options [nop,nop,TS val 1245062659 =
ecr 949460744], length 562
06:35:44.003606 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 79, win 65535, options [nop,nop,TS val 949460783 ecr 1245062659], =
length 0
06:35:44.003743 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 79:159, ack 1, win 8576, options [nop,nop,TS val 1245062659 ecr =
949460744], length 80
06:35:44.003797 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 159, win 65535, options [nop,nop,TS val 949460783 ecr 1245062659], =
length 0
06:35:44.119443 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 159:1607, ack 1, win 8576, options [nop,nop,TS val 1245062687 ecr =
949460783], length 1448
06:35:44.124388 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 1607:3055, ack 1, win 8576, options [nop,nop,TS val 1245062688 ecr =
949460783], length 1448
06:35:44.124465 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 3055, win 65160, options [nop,nop,TS val 949460784 ecr 1245062687], =
length 0
06:35:44.125640 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 3055:4503, ack 1, win 8576, options [nop,nop,TS val 1245062688 ecr =
949460783], length 1448
06:35:44.126066 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 4503:5951, ack 1, win 8576, options [nop,nop,TS val 1245062688 ecr =
949460783], length 1448
06:35:44.126087 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 5951, win 64336, options [nop,nop,TS val 949460784 ecr 1245062688], =
length 0
06:35:44.126641 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 5951:7399, ack 1, win 8576, options [nop,nop,TS val 1245062688 ecr =
949460783], length 1448
06:35:44.239633 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 7399:8847, ack 1, win 8576, options [nop,nop,TS val 1245062717 ecr =
949460784], length 1448
06:35:44.239708 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 8847, win 65160, options [nop,nop,TS val 949460785 ecr 1245062688], =
length 0
06:35:44.250401 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 8847:10295, ack 1, win 8576, options [nop,nop,TS val 1245062717 ecr =
949460784], length 1448
06:35:44.250877 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 10295:11743, ack 1, win 8576, options [nop,nop,TS val 1245062717 ecr =
949460784], length 1448
06:35:44.251385 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 11743:13191, ack 1, win 8576, options [nop,nop,TS val 1245062718 ecr =
949460784], length 1448
06:35:44.251391 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 11743, win 65177, options [nop,nop,TS val 949460785 ecr 1245062717], =
length 0
06:35:44.252158 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 13191:14639, ack 1, win 8576, options [nop,nop,TS val 1245062718 ecr =
949460784], length 1448
06:35:44.252751 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 14639:16087, ack 1, win 8576, options [nop,nop,TS val 1245062718 ecr =
949460784], length 1448
06:35:44.252783 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 16087, win 63736, options [nop,nop,TS val 949460785 ecr 1245062718], =
length 0
06:35:44.366955 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 16087:17535, ack 1, win 8576, options [nop,nop,TS val 1245062747 ecr =
949460785], length 1448
06:35:44.367024 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 17535, win 65185, options [nop,nop,TS val 949460786 ecr 1245062747], =
length 0
06:35:44.368114 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 17535:18983, ack 1, win 8576, options [nop,nop,TS val 1245062747 ecr =
949460785], length 1448
06:35:44.368857 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 18983:20431, ack 1, win 8576, options [nop,nop,TS val 1245062747 ecr =
949460785], length 1448
06:35:44.368893 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 20431, win 65189, options [nop,nop,TS val 949460786 ecr 1245062747], =
length 0
06:35:44.371955 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 20431:21879, ack 1, win 8576, options [nop,nop,TS val 1245062749 ecr =
949460785], length 1448
06:35:44.371968 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 21879, win 65160, options [nop,nop,TS val 949460786 ecr 1245062749], =
length 0
06:35:44.372329 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 21879:23327, ack 1, win 8576, options [nop,nop,TS val 1245062749 ecr =
949460785], length 1448
06:35:44.373724 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 23327:24775, ack 1, win 8576, options [nop,nop,TS val 1245062749 ecr =
949460785], length 1448
06:35:44.374258 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 24775:26223, ack 1, win 8576, options [nop,nop,TS val 1245062750 ecr =
949460785], length 1448
06:35:44.374663 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 26223, win 63712, options [nop,nop,TS val 949460786 ecr 1245062749], =
length 0
06:35:44.374909 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 26223:27671, ack 1, win 8576, options [nop,nop,TS val 1245062750 ecr =
949460785], length 1448
06:35:44.375729 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 27671:29119, ack 1, win 8576, options [nop,nop,TS val 1245062750 ecr =
949460785], length 1448
06:35:44.376224 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 29119:30567, ack 1, win 8576, options [nop,nop,TS val 1245062750 ecr =
949460785], length 1448
06:35:44.376508 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 30567, win 62267, options [nop,nop,TS val 949460786 ecr 1245062750], =
length 0
06:35:44.377860 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 30567, win 65176, options [nop,nop,TS val 949460786 ecr 1245062750], =
length 0
06:35:44.489713 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 32015:32063, ack 1, win 8576, options [nop,nop,TS val 1245062779 ecr =
949460786], length 48
06:35:44.489728 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 30567, win 65535, options [nop,nop,TS val 949460787 ecr =
1245062750,nop,nop,sack 1 {32015:32063}], length 0
06:35:44.490411 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 30567:32015, ack 1, win 8576, options [nop,nop,TS val 1245062779 ecr =
949460786], length 1448
06:35:44.490430 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 32063, win 65112, options [nop,nop,TS val 949460787 ecr 1245062779], =
length 0
06:35:44.494150 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 32063:33511, ack 1, win 8576, options [nop,nop,TS val 1245062779 ecr =
949460786], length 1448
06:35:44.495219 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 33511:34959, ack 1, win 8576, options [nop,nop,TS val 1245062779 ecr =
949460786], length 1448
06:35:44.495495 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 34959, win 65174, options [nop,nop,TS val 949460788 ecr 1245062779], =
length 0
06:35:44.496820 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 34959:36407, ack 1, win 8576, options [nop,nop,TS val 1245062779 ecr =
949460786], length 1448
06:35:44.498865 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 36407:37855, ack 1, win 8576, options [nop,nop,TS val 1245062780 ecr =
949460786], length 1448
06:35:44.499434 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 37855, win 65185, options [nop,nop,TS val 949460788 ecr 1245062779], =
length 0
06:35:44.502185 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 37855:39303, ack 1, win 8576, options [nop,nop,TS val 1245062780 ecr =
949460786], length 1448
06:35:44.506242 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 39303:40751, ack 1, win 8576, options [nop,nop,TS val 1245062780 ecr =
949460786], length 1448
06:35:44.507626 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 40751:42199, ack 1, win 8576, options [nop,nop,TS val 1245062780 ecr =
949460786], length 1448
06:35:44.507637 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 40751, win 65187, options [nop,nop,TS val 949460788 ecr 1245062780], =
length 0
06:35:44.509149 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 42199:43647, ack 1, win 8576, options [nop,nop,TS val 1245062780 ecr =
949460786], length 1448
06:35:44.509622 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 43647, win 65203, options [nop,nop,TS val 949460788 ecr 1245062780], =
length 0
06:35:44.512094 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 43647:45095, ack 1, win 8576, options [nop,nop,TS val 1245062780 ecr =
949460786], length 1448
06:35:44.512109 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 45095, win 65160, options [nop,nop,TS val 949460788 ecr 1245062780], =
length 0
06:35:44.516142 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 45095:46543, ack 1, win 8576, options [nop,nop,TS val 1245062781 ecr =
949460786], length 1448
06:35:44.517290 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 46543:47991, ack 1, win 8576, options [nop,nop,TS val 1245062781 ecr =
949460786], length 1448
06:35:44.517489 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 47991, win 65177, options [nop,nop,TS val 949460788 ecr 1245062781], =
length 0
06:35:44.518697 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 47991:49439, ack 1, win 8576, options [nop,nop,TS val 1245062781 ecr =
949460786], length 1448
06:35:44.521038 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 49439:50887, ack 1, win 8576, options [nop,nop,TS val 1245062781 ecr =
949460786], length 1448
06:35:44.521321 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 50887, win 65193, options [nop,nop,TS val 949460788 ecr 1245062781], =
length 0
06:35:44.618903 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 50887:52335, ack 1, win 8576, options [nop,nop,TS val 1245062812 ecr =
949460787], length 1448
06:35:44.620079 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 52335:53783, ack 1, win 8576, options [nop,nop,TS val 1245062812 ecr =
949460788], length 1448
06:35:44.620503 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 53783, win 65210, options [nop,nop,TS val 949460789 ecr 1245062812], =
length 0
06:35:44.621574 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 53783:55231, ack 1, win 8576, options [nop,nop,TS val 1245062812 ecr =
949460788], length 1448
06:35:44.626146 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 55231:56679, ack 1, win 8576, options [nop,nop,TS val 1245062812 ecr =
949460788], length 1448
06:35:44.626234 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 56679, win 65223, options [nop,nop,TS val 949460789 ecr 1245062812], =
length 0
06:35:44.627224 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 56679:58127, ack 1, win 8576, options [nop,nop,TS val 1245062812 ecr =
949460788], length 1448
06:35:44.627238 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 58127, win 65160, options [nop,nop,TS val 949460789 ecr 1245062812], =
length 0
06:35:44.628991 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 58127:59575, ack 1, win 8576, options [nop,nop,TS val 1245062812 ecr =
949460788], length 1448
06:35:44.631903 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 59575:61023, ack 1, win 8576, options [nop,nop,TS val 1245062813 ecr =
949460788], length 1448
06:35:44.631938 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 61023, win 65171, options [nop,nop,TS val 949460789 ecr 1245062812], =
length 0
06:35:44.632691 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 61023:62471, ack 1, win 8576, options [nop,nop,TS val 1245062813 ecr =
949460788], length 1448
06:35:44.633247 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 62471:63919, ack 1, win 8576, options [nop,nop,TS val 1245062813 ecr =
949460788], length 1448
06:35:44.633509 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 63919, win 65176, options [nop,nop,TS val 949460789 ecr 1245062813], =
length 0
06:35:44.633878 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 63919:65367, ack 1, win 8576, options [nop,nop,TS val 1245062813 ecr =
949460788], length 1448
06:35:44.634535 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 65367:66815, ack 1, win 8576, options [nop,nop,TS val 1245062813 ecr =
949460788], length 1448
06:35:44.634902 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 66815, win 65191, options [nop,nop,TS val 949460789 ecr 1245062813], =
length 0
06:35:44.634966 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 66815:68263, ack 1, win 8576, options [nop,nop,TS val 1245062813 ecr =
949460788], length 1448
06:35:44.635562 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 68263:69711, ack 1, win 8576, options [nop,nop,TS val 1245062814 ecr =
949460788], length 1448
06:35:44.636216 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 69711:71159, ack 1, win 8576, options [nop,nop,TS val 1245062814 ecr =
949460788], length 1448
06:35:44.636231 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 71159, win 63512, options [nop,nop,TS val 949460789 ecr 1245062813], =
length 0
06:35:44.636989 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 71159:72607, ack 1, win 8576, options [nop,nop,TS val 1245062814 ecr =
949460788], length 1448
06:35:44.637660 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 72607, win 64976, options [nop,nop,TS val 949460789 ecr 1245062814], =
length 0
06:35:44.638189 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 72607:74055, ack 1, win 8576, options [nop,nop,TS val 1245062814 ecr =
949460788], length 1448
06:35:44.638786 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 74055:75503, ack 1, win 8576, options [nop,nop,TS val 1245062814 ecr =
949460788], length 1448
06:35:44.639000 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 75503, win 64977, options [nop,nop,TS val 949460789 ecr 1245062814], =
length 0
06:35:44.639297 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 75503:76951, ack 1, win 8576, options [nop,nop,TS val 1245062816 ecr =
949460788], length 1448
06:35:44.640905 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 76951:78399, ack 1, win 8576, options [nop,nop,TS val 1245062816 ecr =
949460788], length 1448
06:35:44.640941 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 78399, win 65165, options [nop,nop,TS val 949460789 ecr 1245062816], =
length 0
06:35:44.642963 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 78399:79847, ack 1, win 8576, options [nop,nop,TS val 1245062816 ecr =
949460788], length 1448
06:35:44.691932 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 79847, win 65535, options [nop,nop,TS val 949460789 ecr 1245062816], =
length 0
06:35:44.736238 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 79847:81295, ack 1, win 8576, options [nop,nop,TS val 1245062842 ecr =
949460789], length 1448
06:35:44.736694 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 81295:82743, ack 1, win 8576, options [nop,nop,TS val 1245062842 ecr =
949460789], length 1448
06:35:44.737084 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 82743:84191, ack 1, win 8576, options [nop,nop,TS val 1245062842 ecr =
949460789], length 1448
06:35:44.737240 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 84191, win 64104, options [nop,nop,TS val 949460790 ecr 1245062842], =
length 0
06:35:44.737880 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 84191:85639, ack 1, win 8576, options [nop,nop,TS val 1245062842 ecr =
949460789], length 1448
06:35:44.738498 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 85639:87087, ack 1, win 8576, options [nop,nop,TS val 1245062842 ecr =
949460789], length 1448
06:35:44.738790 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 87087, win 64117, options [nop,nop,TS val 949460790 ecr 1245062842], =
length 0
06:35:44.738845 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 87087:88535, ack 1, win 8576, options [nop,nop,TS val 1245062842 ecr =
949460789], length 1448
06:35:44.742900 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 88535:89983, ack 1, win 8576, options [nop,nop,TS val 1245062843 ecr =
949460789], length 1448
06:35:44.743784 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 89983, win 64123, options [nop,nop,TS val 949460790 ecr 1245062842], =
length 0
06:35:44.743837 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 89983:91431, ack 1, win 8576, options [nop,nop,TS val 1245062843 ecr =
949460789], length 1448
06:35:44.744477 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 91431:92879, ack 1, win 8576, options [nop,nop,TS val 1245062843 ecr =
949460789], length 1448
06:35:44.744493 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 92879, win 62776, options [nop,nop,TS val 949460790 ecr 1245062843], =
length 0
06:35:44.745150 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 92879:94327, ack 1, win 8576, options [nop,nop,TS val 1245062843 ecr =
949460789], length 1448
06:35:44.745661 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 94327:95775, ack 1, win 8576, options [nop,nop,TS val 1245062843 ecr =
949460789], length 1448
06:35:44.745952 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 95775, win 62788, options [nop,nop,TS val 949460790 ecr 1245062843], =
length 0
06:35:44.754349 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 95775:97223, ack 1, win 8576, options [nop,nop,TS val 1245062846 ecr =
949460789], length 1448
06:35:44.754414 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 97223, win 65167, options [nop,nop,TS val 949460790 ecr 1245062846], =
length 0
06:35:44.754611 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 97223:98671, ack 1, win 8576, options [nop,nop,TS val 1245062846 ecr =
949460789], length 1448
06:35:44.757183 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 98671:100119, ack 1, win 8576, options [nop,nop,TS val 1245062846 =
ecr 949460789], length 1448
06:35:44.757222 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 100119, win 65230, options [nop,nop,TS val 949460790 ecr =
1245062846], length 0
06:35:44.757772 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 100119:101567, ack 1, win 8576, options [nop,nop,TS val 1245062846 =
ecr 949460789], length 1448
06:35:44.758327 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 101567:103015, ack 1, win 8576, options [nop,nop,TS val 1245062846 =
ecr 949460789], length 1448
06:35:44.758485 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 103015, win 65242, options [nop,nop,TS val 949460790 ecr =
1245062846], length 0
06:35:44.759102 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 103015:104463, ack 1, win 8576, options [nop,nop,TS val 1245062846 =
ecr 949460789], length 1448
06:35:44.760342 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 104463:105911, ack 1, win 8576, options [nop,nop,TS val 1245062846 =
ecr 949460789], length 1448
06:35:44.760360 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 105911, win 65160, options [nop,nop,TS val 949460790 ecr =
1245062846], length 0
06:35:44.761173 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 105911:107359, ack 1, win 8576, options [nop,nop,TS val 1245062846 =
ecr 949460789], length 1448
06:35:44.761566 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 107359:108807, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.761962 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 108807:110255, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.761990 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 110255, win 63730, options [nop,nop,TS val 949460790 ecr =
1245062846], length 0
06:35:44.763481 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 110255:111703, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.763533 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 111703, win 65194, options [nop,nop,TS val 949460790 ecr =
1245062847], length 0
06:35:44.764140 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 111703:113151, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.766148 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 113151:114599, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.766233 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 114599, win 65195, options [nop,nop,TS val 949460790 ecr =
1245062847], length 0
06:35:44.767343 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 114599:116047, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.767838 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 116047:117495, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.768062 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 117495, win 65209, options [nop,nop,TS val 949460790 ecr =
1245062847], length 0
06:35:44.768270 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 117495:118943, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.768286 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 118943, win 64217, options [nop,nop,TS val 949460790 ecr =
1245062847], length 0
06:35:44.772004 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 118943:120391, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.773221 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 120391:121839, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.773261 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 121839, win 65178, options [nop,nop,TS val 949460790 ecr =
1245062847], length 0
06:35:44.774020 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 121839:123287, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.774633 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 123287:124735, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.774744 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 124735, win 65178, options [nop,nop,TS val 949460790 ecr =
1245062847], length 0
06:35:44.775063 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 124735:126183, ack 1, win 8576, options [nop,nop,TS val 1245062847 =
ecr 949460789], length 1448
06:35:44.852177 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 126183:127631, ack 1, win 8576, options [nop,nop,TS val 1245062871 =
ecr 949460790], length 1448
06:35:44.852385 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 127631, win 65192, options [nop,nop,TS val 949460791 ecr =
1245062847], length 0
06:35:44.852605 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
seq 127631:129079, ack 1, win 8576, options [nop,nop,TS val 1245062871 =
ecr 949460790], length 1448
06:35:44.854293 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 129079:129916, ack 1, win 8576, options [nop,nop,TS val 1245062871 =
ecr 949460790], length 837
06:35:44.854311 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [.], =
ack 129916, win 65535, options [nop,nop,TS val 949460791 ecr =
1245062871], length 0
06:35:46.072465 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [P.], =
seq 1:24, ack 129916, win 65535, options [nop,nop,TS val 949460803 ecr =
1245062871], length 23
06:35:46.072521 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 129916, win 65535, options [nop,nop,TS val 949460803 ecr =
1245062871], length 0
06:35:46.187126 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
ack 24, win 8576, options [nop,nop,TS val 1245063205 ecr 949460803], =
length 0
06:35:46.187214 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 129916, win 65535, options [nop,nop,TS val 949460804 ecr =
1245063205], length 0
06:35:46.187848 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [P.], =
seq 129916:129939, ack 24, win 8576, options [nop,nop,TS val 1245063205 =
ecr 949460803], length 23
06:35:46.187927 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [R], =
seq 680741279, win 0, length 0
06:35:46.188995 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [F.], =
seq 129939, ack 25, win 8576, options [nop,nop,TS val 1245063205 ecr =
949460803], length 0
06:35:46.189062 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [R], =
seq 680741280, win 0, length 0
06:35:46.190034 IP mail.ietf.org.https > 10.71.5.180.60354: Flags [.], =
ack 25, win 8576, length 0
06:35:46.190081 IP 10.71.5.180.60354 > mail.ietf.org.https: Flags [R], =
seq 680741280, win 0, length 0

--Apple-Mail-105-709146384
Content-Disposition: attachment;
	filename=10.71.5.180.60353.txt
Content-Type: text/plain;
	name="10.71.5.180.60353.txt"
Content-Transfer-Encoding: quoted-printable

06:35:43.943633 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [P.], =
seq 1280403993:1280404072, ack 27321123, win 8576, options [nop,nop,TS =
val 1245062643 ecr 949460745], length 79
06:35:43.943655 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460782 ecr =
1245061742,nop,nop,sack 1 {0:79}], length 0
06:35:43.944240 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [P.], =
seq 79:159, ack 1, win 8576, options [nop,nop,TS val 1245062643 ecr =
949460745], length 80
06:35:43.944259 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 4294966734, win 65535, options [nop,nop,TS val 949460782 ecr =
1245061742,nop,nop,sack 1 {0:159}], length 0
06:35:43.944932 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [P.], =
seq 4294966734:0, ack 1, win 8576, options [nop,nop,TS val 1245062643 =
ecr 949460745], length 562
06:35:43.944952 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 159, win 65535, options [nop,nop,TS val 949460782 ecr 1245062643], =
length 0
06:35:44.061673 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 159:1607, ack 1, win 8576, options [nop,nop,TS val 1245062672 ecr =
949460782], length 1448
06:35:44.062062 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 1607:3055, ack 1, win 8576, options [nop,nop,TS val 1245062672 ecr =
949460782], length 1448
06:35:44.062092 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 3055, win 64120, options [nop,nop,TS val 949460783 ecr 1245062672], =
length 0
06:35:44.062717 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 3055:4503, ack 1, win 8576, options [nop,nop,TS val 1245062672 ecr =
949460782], length 1448
06:35:44.063152 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 4503:5951, ack 1, win 8576, options [nop,nop,TS val 1245062672 ecr =
949460782], length 1448
06:35:44.063169 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 5951, win 63712, options [nop,nop,TS val 949460783 ecr 1245062672], =
length 0
06:35:44.188582 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 5951:7399, ack 1, win 8576, options [nop,nop,TS val 1245062701 ecr =
949460783], length 1448
06:35:44.189232 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 7399:8847, ack 1, win 8576, options [nop,nop,TS val 1245062701 ecr =
949460783], length 1448
06:35:44.189245 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 8847, win 63712, options [nop,nop,TS val 949460784 ecr 1245062701], =
length 0
06:35:44.189930 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 8847:10295, ack 1, win 8576, options [nop,nop,TS val 1245062701 ecr =
949460783], length 1448
06:35:44.190403 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 10295:11743, ack 1, win 8576, options [nop,nop,TS val 1245062701 ecr =
949460783], length 1448
06:35:44.190857 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 11743:13191, ack 1, win 8576, options [nop,nop,TS val 1245062701 ecr =
949460783], length 1448
06:35:44.191136 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 13191, win 62275, options [nop,nop,TS val 949460784 ecr 1245062701], =
length 0
06:35:44.191389 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 13191:14639, ack 1, win 8576, options [nop,nop,TS val 1245062701 ecr =
949460783], length 1448
06:35:44.193089 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 14639, win 63730, options [nop,nop,TS val 949460785 ecr 1245062701], =
length 0
06:35:44.313222 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 14639:16087, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.315702 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 16087, win 65178, options [nop,nop,TS val 949460786 ecr 1245062733], =
length 0
06:35:44.315815 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 16087:17535, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.316923 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 17535:18983, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.317428 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 18983, win 65188, options [nop,nop,TS val 949460786 ecr 1245062733], =
length 0
06:35:44.325919 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 18983:20431, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.327076 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 20431:21879, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.327092 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 21879, win 63712, options [nop,nop,TS val 949460786 ecr 1245062733], =
length 0
06:35:44.327742 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 21879:23327, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.328275 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 23327:24775, ack 1, win 8576, options [nop,nop,TS val 1245062733 ecr =
949460784], length 1448
06:35:44.330692 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 24775:26223, ack 1, win 8576, options [nop,nop,TS val 1245062734 ecr =
949460785], length 1448
06:35:44.331205 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 26223:27671, ack 1, win 8576, options [nop,nop,TS val 1245062734 ecr =
949460785], length 1448
06:35:44.332628 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 27671, win 60834, options [nop,nop,TS val 949460786 ecr 1245062733], =
length 0
06:35:44.333945 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 27671, win 63744, options [nop,nop,TS val 949460786 ecr 1245062733], =
length 0
06:35:44.435622 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 27671:29119, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.436256 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 29119:30567, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.436793 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 30567:32015, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.437127 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 32015, win 62298, options [nop,nop,TS val 949460787 ecr 1245062765], =
length 0
06:35:44.437223 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 32015:33463, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.437899 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 33463:34911, ack 1, win 8576, options [nop,nop,TS val 1245062765 ecr =
949460786], length 1448
06:35:44.437913 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 34911, win 60895, options [nop,nop,TS val 949460787 ecr 1245062765], =
length 0
06:35:44.439220 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 34911, win 63795, options [nop,nop,TS val 949460787 ecr 1245062765], =
length 0
06:35:44.449510 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 34911:36359, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.449635 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 36359, win 65260, options [nop,nop,TS val 949460787 ecr 1245062768], =
length 0
06:35:44.449908 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 36359:37807, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.450464 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 37807:39255, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.451097 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 39255:40703, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.451188 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 40703, win 63834, options [nop,nop,TS val 949460787 ecr 1245062768], =
length 0
06:35:44.451508 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 40703:42151, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.452247 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 42151:43599, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.452741 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 43599:45047, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.453103 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 45047, win 62388, options [nop,nop,TS val 949460787 ecr 1245062768], =
length 0
06:35:44.453272 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 45047:46495, ack 1, win 8576, options [nop,nop,TS val 1245062768 ecr =
949460786], length 1448
06:35:44.454487 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 46495, win 63853, options [nop,nop,TS val 949460787 ecr 1245062768], =
length 0
06:35:44.558027 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 46495:47943, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.558042 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 47943, win 65160, options [nop,nop,TS val 949460788 ecr 1245062795], =
length 0
06:35:44.558820 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 47943:49391, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.559398 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 49391:50839, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.560460 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 50839:52287, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.560739 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 52287, win 63722, options [nop,nop,TS val 949460788 ecr 1245062795], =
length 0
06:35:44.561313 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 52287:53735, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.562463 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 53735:55183, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.562591 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 55183, win 63729, options [nop,nop,TS val 949460788 ecr 1245062795], =
length 0
06:35:44.563675 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 55183:56631, ack 1, win 8576, options [nop,nop,TS val 1245062795 ecr =
949460787], length 1448
06:35:44.564657 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 56631, win 65183, options [nop,nop,TS val 949460788 ecr 1245062795], =
length 0
06:35:44.571296 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 56631:58079, ack 1, win 8576, options [nop,nop,TS val 1245062798 ecr =
949460787], length 1448
06:35:44.571671 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 58079:59527, ack 1, win 8576, options [nop,nop,TS val 1245062798 ecr =
949460787], length 1448
06:35:44.572032 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 59527, win 65199, options [nop,nop,TS val 949460788 ecr 1245062798], =
length 0
06:35:44.572343 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 59527:60975, ack 1, win 8576, options [nop,nop,TS val 1245062798 ecr =
949460787], length 1448
06:35:44.572357 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 60975, win 64332, options [nop,nop,TS val 949460788 ecr 1245062798], =
length 0
06:35:44.573141 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 60975:62423, ack 1, win 8576, options [nop,nop,TS val 1245062798 ecr =
949460787], length 1448
06:35:44.573817 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 62423:63871, ack 1, win 8576, options [nop,nop,TS val 1245062798 ecr =
949460787], length 1448
06:35:44.574063 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 63871, win 64343, options [nop,nop,TS val 949460788 ecr 1245062798], =
length 0
06:35:44.574836 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 63871:65319, ack 1, win 8576, options [nop,nop,TS val 1245062798 ecr =
949460787], length 1448
06:35:44.578120 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 65319:66767, ack 1, win 8576, options [nop,nop,TS val 1245062799 ecr =
949460787], length 1448
06:35:44.578173 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 66767, win 65170, options [nop,nop,TS val 949460788 ecr 1245062798], =
length 0
06:35:44.578454 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 66767:68215, ack 1, win 8576, options [nop,nop,TS val 1245062799 ecr =
949460787], length 1448
06:35:44.579814 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 68215:69663, ack 1, win 8576, options [nop,nop,TS val 1245062799 ecr =
949460787], length 1448
06:35:44.579854 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 69663, win 65180, options [nop,nop,TS val 949460788 ecr 1245062799], =
length 0
06:35:44.580634 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 69663:71111, ack 1, win 8576, options [nop,nop,TS val 1245062799 ecr =
949460787], length 1448
06:35:44.581302 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 71111:72559, ack 1, win 8576, options [nop,nop,TS val 1245062799 ecr =
949460787], length 1448
06:35:44.581362 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 72559, win 65184, options [nop,nop,TS val 949460788 ecr 1245062799], =
length 0
06:35:44.581941 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 72559:74007, ack 1, win 8576, options [nop,nop,TS val 1245062799 ecr =
949460787], length 1448
06:35:44.581957 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 74007, win 64972, options [nop,nop,TS val 949460788 ecr 1245062799], =
length 0
06:35:44.684645 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 74007:75455, ack 1, win 8576, options [nop,nop,TS val 1245062826 ecr =
949460788], length 1448
06:35:44.685176 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 75455:76903, ack 1, win 8576, options [nop,nop,TS val 1245062826 ecr =
949460788], length 1448
06:35:44.685887 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 76903, win 64980, options [nop,nop,TS val 949460789 ecr 1245062826], =
length 0
06:35:44.686916 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 76903:78351, ack 1, win 8576, options [nop,nop,TS val 1245062826 ecr =
949460788], length 1448
06:35:44.687550 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 78351:79799, ack 1, win 8576, options [nop,nop,TS val 1245062826 ecr =
949460788], length 1448
06:35:44.687587 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 79799, win 64990, options [nop,nop,TS val 949460789 ecr 1245062826], =
length 0
06:35:44.687922 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 79799:81247, ack 1, win 8576, options [nop,nop,TS val 1245062826 ecr =
949460788], length 1448
06:35:44.688661 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 81247:82695, ack 1, win 8576, options [nop,nop,TS val 1245062826 ecr =
949460788], length 1448
06:35:44.688996 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 82695, win 64996, options [nop,nop,TS val 949460789 ecr 1245062826], =
length 0
06:35:44.689032 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 82695:84143, ack 1, win 8576, options [nop,nop,TS val 1245062828 ecr =
949460788], length 1448
06:35:44.689403 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 84143:85591, ack 1, win 8576, options [nop,nop,TS val 1245062828 ecr =
949460788], length 1448
06:35:44.690546 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 85591, win 65009, options [nop,nop,TS val 949460789 ecr 1245062828], =
length 0
06:35:44.691798 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 85591:87039, ack 1, win 8576, options [nop,nop,TS val 1245062828 ecr =
949460788], length 1448
06:35:44.691815 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 87039, win 65160, options [nop,nop,TS val 949460789 ecr 1245062828], =
length 0
06:35:44.692150 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 87039:88487, ack 1, win 8576, options [nop,nop,TS val 1245062828 ecr =
949460788], length 1448
06:35:44.693048 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 88487:89935, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.693442 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 89935, win 65169, options [nop,nop,TS val 949460790 ecr 1245062828], =
length 0
06:35:44.694483 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 89935:91383, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.695038 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 91383:92831, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.695216 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 92831, win 65175, options [nop,nop,TS val 949460790 ecr 1245062829], =
length 0
06:35:44.695409 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 92831:94279, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.696067 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 94279:95727, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.696634 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 95727, win 65190, options [nop,nop,TS val 949460790 ecr 1245062829], =
length 0
06:35:44.696718 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 95727:97175, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.697397 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 97175:98623, ack 1, win 8576, options [nop,nop,TS val 1245062829 ecr =
949460788], length 1448
06:35:44.698031 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 98623:100071, ack 1, win 8576, options [nop,nop,TS val 1245062829 =
ecr 949460788], length 1448
06:35:44.698046 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 100071, win 62949, options [nop,nop,TS val 949460790 ecr =
1245062829], length 0
06:35:44.698783 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 100071:101519, ack 1, win 8576, options [nop,nop,TS val 1245062829 =
ecr 949460788], length 1448
06:35:44.699259 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 101519:102967, ack 1, win 8576, options [nop,nop,TS val 1245062830 =
ecr 949460788], length 1448
06:35:44.699483 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 102967, win 62950, options [nop,nop,TS val 949460790 ecr =
1245062829], length 0
06:35:44.699668 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 102967:104415, ack 1, win 8576, options [nop,nop,TS val 1245062830 =
ecr 949460788], length 1448
06:35:44.700365 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 104415:105863, ack 1, win 8576, options [nop,nop,TS val 1245062830 =
ecr 949460788], length 1448
06:35:44.700899 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 105863:107311, ack 1, win 8576, options [nop,nop,TS val 1245062830 =
ecr 949460788], length 1448
06:35:44.700949 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 107311, win 61519, options [nop,nop,TS val 949460790 ecr =
1245062830], length 0
06:35:44.701535 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 107311:108759, ack 1, win 8576, options [nop,nop,TS val 1245062830 =
ecr 949460788], length 1448
06:35:44.702049 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 108759:110207, ack 1, win 8576, options [nop,nop,TS val 1245062830 =
ecr 949460788], length 1448
06:35:44.702268 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 110207, win 61520, options [nop,nop,TS val 949460790 ecr =
1245062830], length 0
06:35:44.702460 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 110207:111655, ack 1, win 8576, options [nop,nop,TS val 1245062831 =
ecr 949460788], length 1448
06:35:44.703196 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
seq 111655:113103, ack 1, win 8576, options [nop,nop,TS val 1245062831 =
ecr 949460788], length 1448
06:35:44.703211 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 113103, win 60291, options [nop,nop,TS val 949460790 ecr =
1245062831], length 0
06:35:44.703744 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [P.], =
seq 113103:114266, ack 1, win 8576, options [nop,nop,TS val 1245062831 =
ecr 949460788], length 1163
06:35:44.703758 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 114266, win 59636, options [nop,nop,TS val 949460790 ecr =
1245062831], length 0
06:35:44.705103 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 114266, win 62535, options [nop,nop,TS val 949460790 ecr =
1245062831], length 0
06:35:44.706884 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [.], =
ack 114266, win 65442, options [nop,nop,TS val 949460790 ecr =
1245062831], length 0
06:35:46.072707 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [P.], =
seq 1:24, ack 114266, win 65535, options [nop,nop,TS val 949460803 ecr =
1245062831], length 23
06:35:46.072735 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 114266, win 65535, options [nop,nop,TS val 949460803 ecr =
1245062831], length 0
06:35:46.189046 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
ack 24, win 8576, options [nop,nop,TS val 1245063204 ecr 949460803], =
length 0
06:35:46.189103 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [F.], =
seq 24, ack 114266, win 65535, options [nop,nop,TS val 949460804 ecr =
1245063204], length 0
06:35:46.189249 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [P.], =
seq 114266:114289, ack 25, win 8576, options [nop,nop,TS val 1245063204 =
ecr 949460803], length 23
06:35:46.189316 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [R], =
seq 27321147, win 0, length 0
06:35:46.189923 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [F.], =
seq 114289, ack 25, win 8576, options [nop,nop,TS val 1245063204 ecr =
949460803], length 0
06:35:46.189981 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [R], =
seq 27321147, win 0, length 0
06:35:46.192804 IP mail.ietf.org.https > 10.71.5.180.60353: Flags [.], =
ack 25, win 8576, length 0
06:35:46.192873 IP 10.71.5.180.60353 > mail.ietf.org.https: Flags [R], =
seq 27321147, win 0, length 0

--Apple-Mail-105-709146384
Content-Disposition: attachment;
	filename=10.71.5.180.60275.txt
Content-Type: text/plain;
	name="10.71.5.180.60275.txt"
Content-Transfer-Encoding: quoted-printable

06:34:20.535536 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [S], seq 3079776104, win 65535, options [mss 1460,nop,wscale =
1,nop,nop,TS val 949459950 ecr 0,sackOK,eol], length 0
06:34:20.541573 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [S.], seq 2124901847, ack 3079776105, win 5672, options [mss =
1430,sackOK,TS val 3394183688 ecr 949459950,nop,wscale 6], length 0
06:34:20.541617 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 1, win 33323, options [nop,nop,TS val 949459950 ecr =
3394183688], length 0
06:34:20.541912 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 1:172, ack 1, win 33323, options [nop,nop,TS val =
949459950 ecr 3394183688], length 171
06:34:20.549544 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [.], ack 172, win 106, options [nop,nop,TS val 3394183696 ecr =
949459950], length 0
06:34:20.554972 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [.], seq 1:1419, ack 172, win 106, options [nop,nop,TS val =
3394183697 ecr 949459950], length 1418
06:34:20.555129 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 1419:1945, ack 172, win 106, options [nop,nop,TS val =
3394183697 ecr 949459950], length 526
06:34:20.555162 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 1945, win 32351, options [nop,nop,TS val 949459950 ecr =
3394183697], length 0
06:34:20.609680 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 172:247, ack 1945, win 33323, options [nop,nop,TS val =
949459951 ecr 3394183697], length 75
06:34:20.609701 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 247:253, ack 1945, win 33323, options [nop,nop,TS val =
949459951 ecr 3394183697], length 6
06:34:20.609719 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 253:294, ack 1945, win 33323, options [nop,nop,TS val =
949459951 ecr 3394183697], length 41
06:34:20.615823 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [.], ack 294, win 106, options [nop,nop,TS val 3394183763 ecr =
949459951], length 0
06:34:20.616262 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 1945:1992, ack 294, win 106, options [nop,nop,TS val =
3394183763 ecr 949459951], length 47
06:34:20.616342 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 1992, win 33299, options [nop,nop,TS val 949459951 ecr =
3394183763], length 0
06:34:20.616742 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 294:858, ack 1992, win 33323, options [nop,nop,TS val =
949459951 ecr 3394183763], length 564
06:34:20.623826 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 1992:3342, ack 858, win 123, options [nop,nop,TS val =
3394183769 ecr 949459951], length 1350
06:34:20.623908 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 3342, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183769], length 0
06:34:20.624161 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 3342:4692, ack 858, win 123, options [nop,nop,TS val =
3394183769 ecr 949459951], length 1350
06:34:20.624224 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 4692, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183769], length 0
06:34:20.625003 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 4692:6042, ack 858, win 123, options [nop,nop,TS val =
3394183769 ecr 949459951], length 1350
06:34:20.625036 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 6042, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183769], length 0
06:34:20.625590 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 6042:6612, ack 858, win 123, options [nop,nop,TS val =
3394183769 ecr 949459951], length 570
06:34:20.625636 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 6612, win 33038, options [nop,nop,TS val 949459951 ecr =
3394183769], length 0
06:34:20.626271 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 6612:7962, ack 858, win 123, options [nop,nop,TS val =
3394183769 ecr 949459951], length 1350
06:34:20.626329 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 7962, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183769], length 0
06:34:20.626951 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 7962:9312, ack 858, win 123, options [nop,nop,TS val =
3394183769 ecr 949459951], length 1350
06:34:20.626998 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 9312, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183769], length 0
06:34:20.629151 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 9312:10662, ack 858, win 123, options [nop,nop,TS val =
3394183770 ecr 949459951], length 1350
06:34:20.629179 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 10662, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183770], length 0
06:34:20.629603 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 10662:10833, ack 858, win 123, options [nop,nop,TS val =
3394183770 ecr 949459951], length 171
06:34:20.629651 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 10833, win 33237, options [nop,nop,TS val 949459951 ecr =
3394183770], length 0
06:34:20.631338 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 10833:12183, ack 858, win 123, options [nop,nop,TS val =
3394183770 ecr 949459951], length 1350
06:34:20.631410 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 12183, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183770], length 0
06:34:20.632044 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 12183:13533, ack 858, win 123, options [nop,nop,TS val =
3394183770 ecr 949459951], length 1350
06:34:20.632070 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 13533, win 32648, options [nop,nop,TS val 949459951 ecr =
3394183770], length 0
06:34:20.633749 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [.], seq 13533:14951, ack 858, win 123, options [nop,nop,TS val =
3394183780 ecr 949459951], length 1418
06:34:20.634203 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 14951:16250, ack 858, win 123, options [nop,nop,TS val =
3394183780 ecr 949459951], length 1299
06:34:20.634254 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 16250, win 32673, options [nop,nop,TS val 949459951 ecr =
3394183780], length 0
06:34:21.348452 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 858:2159, ack 16250, win 33323, options [nop,nop,TS val =
949459958 ecr 3394183780], length 1301
06:34:21.355945 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 16250:16676, ack 2159, win 164, options [nop,nop,TS val =
3394184503 ecr 949459958], length 426
06:34:21.356048 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [.], ack 16676, win 33110, options [nop,nop,TS val 949459958 ecr =
3394184503], length 0
06:34:28.929419 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 2159:3511, ack 16676, win 33323, options [nop,nop,TS val =
949460034 ecr 3394184503], length 1352
06:34:28.930976 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [P.], seq 3511:3538, ack 16676, win 33323, options [nop,nop,TS val =
949460034 ecr 3394184503], length 27
06:34:28.931031 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [F.], seq 3538, ack 16676, win 33323, options [nop,nop,TS val =
949460034 ecr 3394184503], length 0
06:34:28.940690 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [.], ack 3538, win 206, options [nop,nop,TS val 3394192088 ecr =
949460034], length 0
06:34:28.940761 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [F.], seq 3538, ack 16676, win 33323, options [nop,nop,TS val =
949460034 ecr 3394192088], length 0
06:34:28.941316 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [P.], seq 16676:17102, ack 3539, win 206, options [nop,nop,TS val =
3394192088 ecr 949460034], length 426
06:34:28.941392 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [R], seq 3079779643, win 0, length 0
06:34:28.941461 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [F.], seq 17102, ack 3539, win 206, options [nop,nop,TS val =
3394192088 ecr 949460034], length 0
06:34:28.941491 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [R], seq 3079779643, win 0, length 0
06:34:28.943062 IP nrt19s01-in-f30.1e100.net.https > 10.71.5.180.60275: =
Flags [.], ack 3539, win 206, length 0
06:34:28.943139 IP 10.71.5.180.60275 > nrt19s01-in-f30.1e100.net.https: =
Flags [R], seq 3079779643, win 0, length 0

--Apple-Mail-105-709146384--

From wes@mti-systems.com  Thu Mar  8 22:10:02 2012
Return-Path: <wes@mti-systems.com>
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 BCFCA21F85D6 for <behave@ietfa.amsl.com>; Thu,  8 Mar 2012 22:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXoqUN1cxS+c for <behave@ietfa.amsl.com>; Thu,  8 Mar 2012 22:10:02 -0800 (PST)
Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3821F85D4 for <behave@ietf.org>; Thu,  8 Mar 2012 22:10:01 -0800 (PST)
Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q296A1Qc024345 for <behave@ietf.org>; Fri, 9 Mar 2012 01:10:01 -0500
Authentication-Results: cm-omr4 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [69.81.143.202] ([69.81.143.202:24097] helo=[192.168.1.106]) by cm-omr4 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C7/94-14799-9BE995F4; Fri, 09 Mar 2012 01:10:01 -0500
Message-ID: <4F599E5C.5090500@mti-systems.com>
Date: Fri, 09 Mar 2012 01:08:28 -0500
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com> <4F585585.9000706@it.uc3m.es> <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com>
In-Reply-To: <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Murari Sridharan <muraris@microsoft.com>, "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 06:10:02 -0000

On 3/8/2012 5:47 AM, Fred Baker wrote:
> I didn't find a FIN (F without Ack) in any of the examples.

Since FIN is set on packets coming from a synchronized state,
I'm not sure why you would expect to find a bare one without
ACK set as well?  It should fail validity tests on reception
and be ignored if ACK isn't set.  Any stack generating those
would be broken, I believe.

-- 
Wes Eddy
MTI Systems

From fred@cisco.com  Thu Mar  8 22:44:44 2012
Return-Path: <fred@cisco.com>
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 C70AB21F8624 for <behave@ietfa.amsl.com>; Thu,  8 Mar 2012 22:44:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyoZH1S0cJbd for <behave@ietfa.amsl.com>; Thu,  8 Mar 2012 22:44:44 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F398321F85A1 for <behave@ietf.org>; Thu,  8 Mar 2012 22:44:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=940; q=dns/txt; s=iport; t=1331275484; x=1332485084; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=X4Jp35DxxLgvo0zZrQ24WfdK342I3L7PVnRCJDyyGkI=; b=kIBbYNjzLo5CrgGlSu6u1LPSiC7pH9UPQsjtgoCCT89FJjVB6Vti3+Tb Q919/okAsNBXrKq+9q1BrGYrqMobm1lCGGOfFbNXlLDh5r8TRgE+r9cR3 tV4A0IejqhJn94CvJ9IISTyF8mo+uJOvgC10c7NiykGNGOQZiag36S3c1 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMFAGemWU+rRDoG/2dsb2JhbABDszKBeIEHggoBAQEDARIBFBM/BQsLDgouVwY1h2MEAQubMQGeVo9zYwSIUYx3hWaKNIJy
X-IronPort-AV: E=Sophos;i="4.73,556,1325462400"; d="scan'208";a="35312057"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 09 Mar 2012 06:44:43 +0000
Received: from dhcp-64-104-shinjuku-wlan-5-136.cisco.com (dhcp-64-104-shinjuku-wlan-5-136.cisco.com [64.104.5.136]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q296igtg022620; Fri, 9 Mar 2012 06:44:42 GMT
Received: from [127.0.0.1] by dhcp-64-104-shinjuku-wlan-5-136.cisco.com (PGP Universal service); Fri, 09 Mar 2012 15:44:44 +0900
X-PGP-Universal: processed; by dhcp-64-104-shinjuku-wlan-5-136.cisco.com on Fri, 09 Mar 2012 15:44:44 +0900
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4F599E5C.5090500@mti-systems.com>
Date: Fri, 9 Mar 2012 15:44:31 +0900
Message-Id: <F4CB9073-4671-496B-BBAB-048FFB14387D@cisco.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com> <4F585585.9000706@it.uc3m.es> <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com> <4F599E5C.5090500@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Murari Sridharan <muraris@microsoft.com>, "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 06:44:44 -0000

On Mar 9, 2012, at 3:08 PM, Wesley Eddy wrote:

> On 3/8/2012 5:47 AM, Fred Baker wrote:
>> I didn't find a FIN (F without Ack) in any of the examples.
>=20
> Since FIN is set on packets coming from a synchronized state,
> I'm not sure why you would expect to find a bare one without
> ACK set as well? =20

You missed it. The sequence is FIN, FIN-ACK, ACK.=20

http://tools.ietf.org/html/rfc793, and look at the transitions=20
	SYN RCVD -> FIN-WAIT-1
	ESTAB    -> FIN-WAIT-1
        ESTAB    -> CLOSE WAIT

What's there is FIN-ACK, RST. No FIN. I could understand FIN, FIN-ACK, =
RST (the guy sends FIN and closes the socket instantly), whether or not =
I agree with it. No FIN - I'm trying to figure out why there was a =
FIN-ACK.

> It should fail validity tests on reception
> and be ignored if ACK isn't set.  Any stack generating those
> would be broken, I believe.
>=20
> --=20
> Wes Eddy
> MTI Systems


From cb.list6@gmail.com  Fri Mar  9 07:30:10 2012
Return-Path: <cb.list6@gmail.com>
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 D085C21F86CF for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 07:30:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.443
X-Spam-Level: 
X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ddbGDQJzRUg for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 07:30:10 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5050221F86C9 for <behave@ietf.org>; Fri,  9 Mar 2012 07:30:10 -0800 (PST)
Received: by pbbrq13 with SMTP id rq13so2873630pbb.31 for <behave@ietf.org>; Fri, 09 Mar 2012 07:30:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xDqF/qZBB7mz0VnZUQau78JcafBhYM7eO+5+bpRO41Q=; b=UubYalDmedrGCtMN1FWVLxHwg688tLbVMVfWj+OInmX7qy62J2R4yLasggwmCj4I0O ouT1nQXqMsmQAlEcohBJg9/2O0+RHna4QX2qD+Jhc4ZiVokLYXeL+j0vHrMVpqbgDAmN oZmXzAO20lCpFgrMWy2qCFj5Q1mbg9L4WkCM4liAvSFK8Rga20jqFyj3Px+/lkgWuOhy KhxZUeds/zbTQpoGIQeSgWvAypF9K4qdiaVI6B5XqnbmBjiY0a2Q8hGGece8T9WVt4yL Ckvwk5kqZ+AjDlg87KrrFxi45n80nnr5wAVe78NtSWdSMADX1IZddOdPd8jS2GEdBbG+ bJlA==
MIME-Version: 1.0
Received: by 10.68.216.138 with SMTP id oq10mr4059832pbc.85.1331307010155; Fri, 09 Mar 2012 07:30:10 -0800 (PST)
Received: by 10.142.163.16 with HTTP; Fri, 9 Mar 2012 07:30:10 -0800 (PST)
Received: by 10.142.163.16 with HTTP; Fri, 9 Mar 2012 07:30:10 -0800 (PST)
In-Reply-To: <CAD6AjGTbjK4RJL2g6_HKFm832z1aQozsy5T5O7dboE_WthYuUw@mail.gmail.com>
References: <CAD6AjGTbjK4RJL2g6_HKFm832z1aQozsy5T5O7dboE_WthYuUw@mail.gmail.com>
Date: Fri, 9 Mar 2012 07:30:10 -0800
Message-ID: <CAD6AjGQ=p-dWX+T7Ssq4DJNNZ8SFO-Vrp5SWXWuqtfy=omOrNw@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: behave@ietf.org
Content-Type: multipart/alternative; boundary=047d7b2e090d6d634704bad1113d
Subject: [BEHAVE] Port overloading
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 15:30:10 -0000

--047d7b2e090d6d634704bad1113d
Content-Type: text/plain; charset=ISO-8859-1

RFC 4787 says one must not use port overloading, can someone briefly
expound on why?

I assume it is so that STUN and now PCP may work with end point independent
mapping , but in many cases STUN does not work because endpoint dependent
mapping (symmetric Nat) is used,.... always been used in some places.... no
need to change. This is my case.

But we are getting into a state on the internet where port overloading will
be required to allow NAT session creation to exceed 64k ports and thus
providing substantial utility to those  that are already on the CGN path
but find that they do not have enough ipv4 addresses to feed the CGN in
order to keep up with increasing ipv4 session demand, including session
growth from NAT64.

Commercial implementation for breaking the 64k port barrier with
overloading  already exists with the explicit purpose of extending the
efficiency of ipv4 pools in CGN and nat64.

If I already have symmetric nat, is port overloading going to break more
things?

This is also relevant to the discussion of fixed port solutions like MAP vs
dynamic solutions like NAT64 and 464XLAT.

Cb

--047d7b2e090d6d634704bad1113d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>RFC 4787 says one must not use port overloading, can someone briefly exp=
ound on why?</p>
<p>I assume it is so that STUN and now PCP may work with end point independ=
ent mapping , but in many cases STUN does not work because endpoint depende=
nt mapping (symmetric Nat) is used,.... always been used in some places....=
 no need to change. This is my case. </p>

<p>But we are getting into a state on the internet where port overloading w=
ill be required to allow NAT session creation to exceed 64k ports and thus =
providing substantial utility to those=A0 that are already on the CGN path =
but find that they do not have enough ipv4 addresses to feed the CGN in ord=
er to keep up with increasing ipv4 session demand, including session growth=
 from NAT64. </p>

<p>Commercial implementation for breaking the 64k port barrier with overloa=
ding=A0 already exists with the explicit purpose of extending the efficienc=
y of ipv4 pools in CGN and nat64. </p>
<p>If I already have symmetric nat, is port overloading going to break more=
 things? </p>
<p>This is also relevant to the discussion of fixed port solutions like MAP=
 vs dynamic solutions like NAT64 and 464XLAT. </p>
<p>Cb</p>

--047d7b2e090d6d634704bad1113d--

From ssenthil@cisco.com  Fri Mar  9 10:37:07 2012
Return-Path: <ssenthil@cisco.com>
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 10AD321E8071 for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 10:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.051
X-Spam-Level: 
X-Spam-Status: No, score=-8.051 tagged_above=-999 required=5 tests=[AWL=1.151,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-8umefjwK5k for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 10:37:06 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3A84521F8739 for <behave@ietf.org>; Fri,  9 Mar 2012 10:37:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=5123; q=dns/txt; s=iport; t=1331318226; x=1332527826; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=+zM7+JXVG89x+8vzV2OCswO6hTxoOrUVe1na0rAq7nQ=; b=AwvGMlNunC4m8WVNBn2l1F2QffAD0Dzovy7rbRE7LQ3H/pR+JoxHxnlx axsfyjJWn3vohRCeYU8yoEeB6gJ1d6sg8PU1aXQcz99PrFLSBCFlrQzSq i3r6TP2LMuVYdYTrfjPszfO+bAk70h5gO/ggrPtamolP403iw2hk7tE3k 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMtMWk+rRDoG/2dsb2JhbABDgkWxenSBB4IKAQEBAwEBAQEPASoxEA0BCAQFBVkGMAEBBAESCRIHh2MEAQucBwGefok8hzwEiCAzhSOHU4skhHiDAQ
X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="32610412"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 09 Mar 2012 18:37:05 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29Ib5sq014910; Fri, 9 Mar 2012 18:37:05 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 9 Mar 2012 10:37:06 -0800
Received: from 10.150.24.245 ([10.150.24.245]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ;  Fri,  9 Mar 2012 18:37:05 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 09 Mar 2012 13:37:04 -0500
From: ssenthil <ssenthil@cisco.com>
To: Cameron Byrne <cb.list6@gmail.com>, <behave@ietf.org>
Message-ID: <CB7FB800.247CF%ssenthil@cisco.com>
Thread-Topic: [BEHAVE] Port overloading
Thread-Index: Acz+I599kMyqa44/o0qqK78f2Bceqw==
In-Reply-To: <CAD6AjGQ=p-dWX+T7Ssq4DJNNZ8SFO-Vrp5SWXWuqtfy=omOrNw@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3414145024_2838449"
X-OriginalArrivalTime: 09 Mar 2012 18:37:06.0073 (UTC) FILETIME=[A0B99890:01CCFE23]
Subject: Re: [BEHAVE] Port overloading
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 18:37:07 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3414145024_2838449
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

If you already have a symmetric NAT, you probably wont lose much by doing
port overloading. But if you are making your NATs application friendly and
wanting to support P2P apps, then port overloading is bad. I recently wrote
a draft on the harmful effects of EDM and port overloading
http://www.ietf.org/internet-drafts/draft-sivakumar-behave-edm-harmful-00.t=
x
t

Thanks
Senthil

On 3/9/12 10:30 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

> RFC 4787 says one must not use port overloading, can someone briefly expo=
und
> on why?
>=20
> I assume it is so that STUN and now PCP may work with end point independe=
nt
> mapping , but in many cases STUN does not work because endpoint dependent
> mapping (symmetric Nat) is used,.... always been used in some places.... =
no
> need to change. This is my case.
>=20
> But we are getting into a state on the internet where port overloading wi=
ll be
> required to allow NAT session creation to exceed 64k ports and thus provi=
ding
> substantial utility to those=A0 that are already on the CGN path but find t=
hat
> they do not have enough ipv4 addresses to feed the CGN in order to keep u=
p
> with increasing ipv4 session demand, including session growth from NAT64.
>=20
> Commercial implementation for breaking the 64k port barrier with overload=
ing=A0
> already exists with the explicit purpose of extending the efficiency of i=
pv4
> pools in CGN and nat64.
>=20
> If I already have symmetric nat, is port overloading going to break more
> things?=20
>=20
> This is also relevant to the discussion of fixed port solutions like MAP =
vs
> dynamic solutions like NAT64 and 464XLAT.
>=20
> Cb
>=20
>=20
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave


--B_3414145024_2838449
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [BEHAVE] Port overloading</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>If you already have a symmetric NAT, you probably wont lose much by doing =
port overloading. But if you are making your NATs application friendly and w=
anting to support P2P apps, then port overloading is bad. I recently wrote a=
 draft on the harmful effects of EDM and port overloading <BR>
</SPAN></FONT><FONT COLOR=3D"#1536EE"><FONT SIZE=3D"2"><FONT FACE=3D"Courier, Cou=
rier New"><SPAN STYLE=3D'font-size:10pt'><U><a href=3D"http://www.ietf.org/inter=
net-drafts/draft-sivakumar-behave-edm-harmful-00.txt">http://www.ietf.org/in=
ternet-drafts/draft-sivakumar-behave-edm-harmful-00.txt</a><BR>
</U></SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Ar=
ial"><SPAN STYLE=3D'font-size:11pt'><BR>
Thanks<BR>
Senthil<BR>
<BR>
On 3/9/12 10:30 AM, &quot;Cameron Byrne&quot; &lt;<a href=3D"cb.list6@gmail.c=
om">cb.list6@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>RFC 4787 says one must not use port overloading,=
 can someone briefly expound on why?<BR>
<BR>
I assume it is so that STUN and now PCP may work with end point independent=
 mapping , but in many cases STUN does not work because endpoint dependent m=
apping (symmetric Nat) is used,.... always been used in some places.... no n=
eed to change. This is my case. <BR>
<BR>
But we are getting into a state on the internet where port overloading will=
 be required to allow NAT session creation to exceed 64k ports and thus prov=
iding substantial utility to those=A0 that are already on the CGN path but fin=
d that they do not have enough ipv4 addresses to feed the CGN in order to ke=
ep up with increasing ipv4 session demand, including session growth from NAT=
64. <BR>
<BR>
Commercial implementation for breaking the 64k port barrier with overloadin=
g=A0 already exists with the explicit purpose of extending the efficiency of i=
pv4 pools in CGN and nat64. <BR>
<BR>
If I already have symmetric nat, is port overloading going to break more th=
ings? <BR>
<BR>
This is also relevant to the discussion of fixed port solutions like MAP vs=
 dynamic solutions like NAT64 and 464XLAT. <BR>
<BR>
Cb<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Behave mailing list<BR>
<a href=3D"Behave@ietf.org">Behave@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/behave">https://www.ietf.org=
/mailman/listinfo/behave</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3414145024_2838449--


From cb.list6@gmail.com  Fri Mar  9 10:45:27 2012
Return-Path: <cb.list6@gmail.com>
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 A7EE521E807E for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 10:45:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.446
X-Spam-Level: 
X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roV0QHXxhZkR for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 10:45:27 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4936C21F86F6 for <behave@ietf.org>; Fri,  9 Mar 2012 10:45:17 -0800 (PST)
Received: by dakl33 with SMTP id l33so1890580dak.31 for <behave@ietf.org>; Fri, 09 Mar 2012 10:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fg/3gwTsK6nArjO2Uyf7k8y46PqH2BMJdOmaE6i3iBs=; b=scf604zPA8x3dG0J1Y6MNQHgAkIt8FA1+N0fLwx1wbG6DYfMDSvZllLegliWkQQJug sC1mMN4RYUDDj/hyb1Q7VUJQwoDefX83QO1joLPaRvJsKztoqJFzdhtmikMsUqg1MrNZ i1NEg8BSaTUovv0ejevxtGobhZFiP5fsBUuZ3myIJWAPVUUfwrOz3WR4k5hJtRdHg/qd +8Ffn8xsjwE7JsMvaLfRPKWMdeshBYNNRxK7RAaFkqTlO/zdHCnWVbKnc0/BHGUDej0M RPGJ8K0ucZkScn0z9wA7qPybxHDAphCS0stQ4beK5ExPDlAKBGHVX9Z+FW6p5zSNquje IyCw==
MIME-Version: 1.0
Received: by 10.68.241.131 with SMTP id wi3mr6147079pbc.1.1331318717023; Fri, 09 Mar 2012 10:45:17 -0800 (PST)
Received: by 10.142.163.16 with HTTP; Fri, 9 Mar 2012 10:45:16 -0800 (PST)
In-Reply-To: <CB7FB800.247CF%ssenthil@cisco.com>
References: <CAD6AjGQ=p-dWX+T7Ssq4DJNNZ8SFO-Vrp5SWXWuqtfy=omOrNw@mail.gmail.com> <CB7FB800.247CF%ssenthil@cisco.com>
Date: Fri, 9 Mar 2012 10:45:16 -0800
Message-ID: <CAD6AjGSqVqc6Wk7WQwg7_f+DMNAjzTkbdE9bmheaw7snyRKuLw@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: ssenthil <ssenthil@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] Port overloading
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 18:45:27 -0000

On Fri, Mar 9, 2012 at 10:37 AM, ssenthil <ssenthil@cisco.com> wrote:
> If you already have a symmetric NAT, you probably wont lose much by doing
> port overloading. But if you are making your NATs application friendly an=
d
> wanting to support P2P apps, then port overloading is bad. I recently wro=
te
> a draft on the harmful effects of EDM and port overloading
> http://www.ietf.org/internet-drafts/draft-sivakumar-behave-edm-harmful-00=
.txt
>

Great, i think you answer my question and i will review the draft as well.

I would like to underscore that APNIC is already out of addresses, and
soon RIPE will go into their end run mode where the max allocation is
/22.  A /22 cannot support a very large EIM CGN, so EDM and port
overloading are an obvious solutions that CGN / NAT64 operators will
have no choice but to accept port overload to extend the limited IPv4
space beyond 64k sessions per IPv4.

Application friendly NATs are a day late and dollar short IMHO, as the
saying goes.  IPv4 will be continued to be watered down.  For my
customers and application developers, i suggest they use IPv6 if
symmetric NAT does not work out for them

CB
> Thanks
> Senthil
>
>
> On 3/9/12 10:30 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:
>
> RFC 4787 says one must not use port overloading, can someone briefly expo=
und
> on why?
>
> I assume it is so that STUN and now PCP may work with end point independe=
nt
> mapping , but in many cases STUN does not work because endpoint dependent
> mapping (symmetric Nat) is used,.... always been used in some places.... =
no
> need to change. This is my case.
>
> But we are getting into a state on the internet where port overloading wi=
ll
> be required to allow NAT session creation to exceed 64k ports and thus
> providing substantial utility to those=A0 that are already on the CGN pat=
h but
> find that they do not have enough ipv4 addresses to feed the CGN in order=
 to
> keep up with increasing ipv4 session demand, including session growth fro=
m
> NAT64.
>
> Commercial implementation for breaking the 64k port barrier with
> overloading=A0 already exists with the explicit purpose of extending the
> efficiency of ipv4 pools in CGN and nat64.
>
> If I already have symmetric nat, is port overloading going to break more
> things?
>
> This is also relevant to the discussion of fixed port solutions like MAP =
vs
> dynamic solutions like NAT64 and 464XLAT.
>
> Cb
>
> ________________________________
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From wes@mti-systems.com  Fri Mar  9 21:14:31 2012
Return-Path: <wes@mti-systems.com>
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 EA28611E8076 for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 21:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVMYakwxhGhD for <behave@ietfa.amsl.com>; Fri,  9 Mar 2012 21:14:31 -0800 (PST)
Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65911E8073 for <behave@ietf.org>; Fri,  9 Mar 2012 21:14:31 -0800 (PST)
Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q2A5EUqX030464 for <behave@ietf.org>; Sat, 10 Mar 2012 00:14:30 -0500
Authentication-Results: cm-omr2 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [69.81.143.202] ([69.81.143.202:10692] helo=[192.168.1.106]) by cm-omr2 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9F/A7-09323-633EA5F4; Sat, 10 Mar 2012 00:14:30 -0500
Message-ID: <4F5AE2D9.1060100@mti-systems.com>
Date: Sat, 10 Mar 2012 00:12:57 -0500
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com> <4F585585.9000706@it.uc3m.es> <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com> <4F599E5C.5090500@mti-systems.com> <F4CB9073-4671-496B-BBAB-048FFB14387D@cisco.com>
In-Reply-To: <F4CB9073-4671-496B-BBAB-048FFB14387D@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Murari Sridharan <muraris@microsoft.com>, "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Mar 2012 05:14:32 -0000

On 3/9/2012 1:44 AM, Fred Baker wrote:
> 
> On Mar 9, 2012, at 3:08 PM, Wesley Eddy wrote:
> 
>> On 3/8/2012 5:47 AM, Fred Baker wrote:
>>> I didn't find a FIN (F without Ack) in any of the examples.
>>
>> Since FIN is set on packets coming from a synchronized state,
>> I'm not sure why you would expect to find a bare one without
>> ACK set as well?  
> 
> You missed it. The sequence is FIN, FIN-ACK, ACK. 
> 
> http://tools.ietf.org/html/rfc793, and look at the transitions 
> 	SYN RCVD -> FIN-WAIT-1
> 	ESTAB    -> FIN-WAIT-1
>         ESTAB    -> CLOSE WAIT
> 
> What's there is FIN-ACK, RST. No FIN. I could understand FIN, FIN-ACK, RST (the guy sends FIN and closes the socket instantly), whether or not I agree with it. No FIN - I'm trying to figure out why there was a FIN-ACK.
> 

When you say "FIN-ACK", I think you're confusing a packet
having those two bits set with a packet that ACKs the FIN
psuedobyte.  All FINs should have the ACK bit set; a bare
FIN would be bogus.

Just looking at one of the trace files you sent
("10.71.5.180.60357.txt"), the beginning of the connection
closure process begins at the line with the timestamp of
06:35:47.021523, which I assume is a TLS closure alert.
That's followed by the TCP FIN at subsecond 021552.  I'm
not sure why you say there is no FIN.  Of course the ACK
bit is set ... the connection is in a synchronized state
and it has to be set for the segment to be accepted.

At this point, I think your machine tosses the connection
state.

When mail.ietf.org sends back its own TLS closure alert
and TCP FIN, logged at subseconds 088808 and 088813.
Those generate RSTs, since you've already released the
connection.  Before the server sees those, it also
ACKs your TLS closure alert (subsecond 139113) and then it
gives you the FIN's ACK (subsecond 140386), both of which
also generate RSTs.

So, I'm not sure what you find unusual here.  It looks
fairly normal to me.

-- 
Wes Eddy
MTI Systems

From cb.list6@gmail.com  Sat Mar 10 05:50:40 2012
Return-Path: <cb.list6@gmail.com>
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 4362A21F85EF for <behave@ietfa.amsl.com>; Sat, 10 Mar 2012 05:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level: 
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ-Q0raU4cWO for <behave@ietfa.amsl.com>; Sat, 10 Mar 2012 05:50:39 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5380321F858D for <behave@ietf.org>; Sat, 10 Mar 2012 05:50:39 -0800 (PST)
Received: by dakl33 with SMTP id l33so2981562dak.31 for <behave@ietf.org>; Sat, 10 Mar 2012 05:50:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y014vEm0fcEVm1GZWihC7kdRXSQxnET0EFvM2sG8HRk=; b=BzpjW/p5DvQa+ootZ13CMZf5DpfVnJpNUQDe2t0y7S7O5JutEavxVOl9dGmdtK+URa zC9ZRnU6PakM5AJIlUHQYQdl0Ux5JvML8toZT42JBZoxgWoqxuriB6mT/iwe923eV/wy xiQ7AzzK+mk7kTySP/vMJ/tvBpqcfs5SqHt1cgEDhshX+UFZYU9jzAqaHBbsRRPVNlAk sBiNQRsD8iK+rc1IuPn66ziwkTXQxsWzEr909GqnVezkIiMVloMAUVck9dezsy9cIUWk lB5JNIBFejr9/9Y1W6Rb3HRx7jQJO3hxneawcbrfpvUXq2QNr/eTZX+lbYu++cVwJk5N U6+A==
MIME-Version: 1.0
Received: by 10.68.129.100 with SMTP id nv4mr8975191pbb.109.1331387439134; Sat, 10 Mar 2012 05:50:39 -0800 (PST)
Received: by 10.142.163.16 with HTTP; Sat, 10 Mar 2012 05:50:39 -0800 (PST)
Date: Sat, 10 Mar 2012 05:50:39 -0800
Message-ID: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: behave@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Mar 2012 13:50:40 -0000

Citing some RIR policy

http://www.apnic.net/community/ipv4-exhaustion/exhaustion-and-network-operators

http://www.ripe.net/ripe/docs/ripe-530#----use-of-last-/8-for-pa-allocations

The 2 above policies, already in force in APNIC and soon to be in
force in RIPE, say a new entrant can only get a /22, 1,024 IPv4
addresses

Trying to keep the math simple here, 64,000 available ports * 1024
IPv4 addresses = 65.5 million sessions.  Just as one data point, i
cannot run my network on this allocation, assuming i put 100% of the
allocation to CGN use.

This brings me to my questions about the draft, it states:

"While it is tempting to maximize the return on the investment by
   maximizing the use of the existing IPv4 addresses, doing End point
   dependent mapping, the harmful effects of this overrides any benefits
   that it offers."

Can this be quantified?  It sounds a bit hand wavy to me.  Especially
since you are essentially saying that there is NO business case for
any new entrant to enter the IPv4 large service provider space, since
EIM is required and IPv4 allocations to support EIM are not available
at large scale.   Does this make sense

Next

"Peer to Peer applications are becoming very common and some real life
   examples of P2P applications are SIP used by VoIP service providers,
   instant messaging, voice and video chat, Google Talk, Apple Facetime
   and several famous gaming applications.  The notion of not supporting
   P2P applications is not just practical and NATs MUST be designed to
   facilitate these applications."

You are equating things that are not equals. Correct, some variations
of SIP do not work without ALGs in EDM NATs.  But, ALGs do make some
protocols work, like some types of SIP (there are too many types of
SIP to make broad statements).  Separately, it is my experience that
various video chat applications like Google Talk work across EDM NATs
without ALGs, ...same with Skype and other so called p2p applications.

So, you may want to change the language above to be more specific
about what exactly breaks and why... and avoid painting with a broad
brush .... and avoid listing applications that DO work with EDM like
Google Talk (yes, relays are used... but the important thing is the
service works for the customer)

Overall, i am opposed to this draft saying EDM is harmful, you are
better off saying IPv4 exhaustion is harmful.  EDM is quite common
today.  Saying EDM is bad is not helpful, but a technical discussion
about pros and cons of EIM and EDM would be helpful.  There will be
more pressure to use EDM as IPv4 exhaustion intensifies.

CB

From fred@cisco.com  Sat Mar 10 09:21:28 2012
Return-Path: <fred@cisco.com>
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 DA54621F8595 for <behave@ietfa.amsl.com>; Sat, 10 Mar 2012 09:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.01
X-Spam-Level: 
X-Spam-Status: No, score=-109.01 tagged_above=-999 required=5 tests=[AWL=1.589, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8uXVew7l32W for <behave@ietfa.amsl.com>; Sat, 10 Mar 2012 09:21:28 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 113CA21F858B for <behave@ietf.org>; Sat, 10 Mar 2012 09:21:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=243; q=dns/txt; s=iport; t=1331400088; x=1332609688; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=clgNXldtXzgxUzmb1BzHOlnCZTqfk7CV0Stt3k8yWcU=; b=UqTUwBXMOj6oBS2kiYb+uziK1qnrI9XTVMCorlLCGh+yA/WKvpTmu6K7 wTtSusVJhNCRKcse0qGNqRyywoPRwmHYzKf1BjdeLpdp/a7lRTBg9+u/U k6CDgCloNWK5ogHZsO+3aEFbxiYfwpU3VJOBswfQPXPQqiCa/gpBMwVad E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqoFANqMW0+rRDoJ/2dsb2JhbAA8BrNdgW+BB4IJAQEBAwESASc/BQsLDjhXBjWHYwSgGwGWQoo/hV9jBIhUjHiFaYo6gwQ
X-IronPort-AV: E=Sophos;i="4.73,563,1325462400"; d="scan'208";a="35390404"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 10 Mar 2012 17:21:28 +0000
Received: from Freds-Computer.local (sjc-vpn6-61.cisco.com [10.21.120.61]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2AHLRu8025311; Sat, 10 Mar 2012 17:21:27 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 10 Mar 2012 09:21:29 -0800
X-PGP-Universal: processed; by Freds-Computer.local on Sat, 10 Mar 2012 09:21:29 -0800
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4F5AE2D9.1060100@mti-systems.com>
Date: Sat, 10 Mar 2012 09:20:46 -0800
Message-Id: <F1233954-FBC7-40FC-9F79-E91E13DC9B27@cisco.com>
References: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com> <4F585585.9000706@it.uc3m.es> <A89221DA-7F68-4EB2-AA7E-17DA3732937C@cisco.com> <4F599E5C.5090500@mti-systems.com> <F4CB9073-4671-496B-BBAB-048FFB14387D@cisco.com> <4F5AE2D9.1060100@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Murari Sridharan <muraris@microsoft.com>, "behave@ietf.org" <behave@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Mar 2012 17:21:29 -0000

On Mar 9, 2012, at 9:12 PM, Wesley Eddy wrote:

> So, I'm not sure what you find unusual here.  It looks
> fairly normal to me.

well, I guess I need to re-read the spec. But the presence of a RST is =
what Marcelo was asking about.=

From internet-drafts@ietf.org  Sun Mar 11 15:11:18 2012
Return-Path: <internet-drafts@ietf.org>
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 E7C1221F868A; Sun, 11 Mar 2012 15:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk5MQM98RMT8; Sun, 11 Mar 2012 15:11:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE4421F864E; Sun, 11 Mar 2012 15:11:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120311221118.5973.39723.idtracker@ietfa.amsl.com>
Date: Sun, 11 Mar 2012 15:11:18 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-sctpnat-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Mar 2012 22:11:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Behavior Engineering for Hindrance Av=
oidance Working Group of the IETF.

	Title           : Stream Control Transmission Protocol (SCTP) Network Addr=
ess Translation
	Author(s)       : Randall R. Stewart
                          Michael Tuexen
                          Irene Ruengeler
	Filename        : draft-ietf-behave-sctpnat-06.txt
	Pages           : 27
	Date            : 2012-03-11

   Stream Control Transmission Protocol [RFC4960] provides a reliable
   communications channel between two end-hosts in many ways similar to
   TCP [RFC0793].  With the widespread deployment of Network Address
   Translators (NAT), specialized code has been added to NAT for TCP
   that allows multiple hosts to reside behind a NAT and yet use only a
   single globally unique IPv4 address, even when two hosts (behind a
   NAT) choose the same port numbers for their connection.  This
   additional code is sometimes classified as Network Address and Port
   Translation or NAPT.  To date, specialized code for SCTP has NOT yet
   been added to most NATs so that only pure NAT is available.  The end
   result of this is that only one SCTP capable host can be behind a
   NAT.

   This document describes an SCTP specific variant of NAT which
   provides similar features of NAPT in the single point and multi-point
   traversal scenario.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-06.txt


From internet-drafts@ietf.org  Mon Mar 12 02:40:11 2012
Return-Path: <internet-drafts@ietf.org>
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 4AB3A21F8750; Mon, 12 Mar 2012 02:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SgqpOhHBvRQ; Mon, 12 Mar 2012 02:40:10 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7243D21F8585; Mon, 12 Mar 2012 02:40:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120312094010.14564.47116.idtracker@ietfa.amsl.com>
Date: Mon, 12 Mar 2012 02:40:10 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 09:40:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Behavior Engineering for Hindrance Av=
oidance Working Group of the IETF.

	Title           : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
	Author(s)       : Teemu Savolainen
                          Jouni Korhonen
                          Dan Wing
	Filename        : draft-ietf-behave-nat64-discovery-heuristic-06.txt
	Pages           : 14
	Date            : 2012-03-12

   This document describes a method for detecting presence of DNS64 and
   for learning IPv6 prefix used for protocol translation on an access
   network.  The method depends on existence of a well-known IPv4-only
   domain name "ipv4only.arpa".  The information learned enables nodes
   to perform local IPv6 address synthesis and to potentially avoid
   traversal through NAT64 on dual-stack accesses and multi-interface
   deployments.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri=
stic-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris=
tic-06.txt


From teemu.savolainen@nokia.com  Mon Mar 12 02:51:11 2012
Return-Path: <teemu.savolainen@nokia.com>
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 9032321F86B0 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 02:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.384
X-Spam-Level: 
X-Spam-Status: No, score=-4.384 tagged_above=-999 required=5 tests=[AWL=2.215,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYIWhxyxaXoi for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 02:51:11 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4521F86A4 for <behave@ietf.org>; Mon, 12 Mar 2012 02:51:10 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2C9p8Vb004661 for <behave@ietf.org>; Mon, 12 Mar 2012 11:51:09 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 11:51:08 +0200
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Mon, 12 Mar 2012 10:51:08 +0100
From: <teemu.savolainen@nokia.com>
To: <behave@ietf.org>
Thread-Topic: New revision: draft-ietf-behave-nat64-discovery-heuristic-06.txt
Thread-Index: Ac0ANTRxb926yBqKSziKyDiihsIwig==
Date: Mon, 12 Mar 2012 09:51:07 +0000
Message-ID: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GEPhoRuzW1ko5yJqzbgD3+YMDmZA3RGQO7V2F0eItf5YQy5DyTDpJIl4NrkEGgbR6YYErH4WRNUORPzeBmBUpoF4XuFNPRkYjgRqOxX5psi3IEJcSBKNpABvmq6A61NjAW+mx9Eep/NxJYJqtdENMesdh8e2JXd28UXYxZXJbDkNzIxPw9MoHJrdvov+54zatg9XTZpB4eALu3PwT24KGLpz/X6T3v6IvYuIr/3pM+4ALzq9wEQcT3iUoXRs+zCH/mRsDGFinhv1cgfhso9dsac=
x-originating-ip: [10.162.86.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2012 09:51:08.0687 (UTC) FILETIME=[A64BE1F0:01CD0035]
X-Nokia-AV: Clean
Subject: [BEHAVE] New revision: draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 09:51:11 -0000

Hi behave WG,

In the last interim we discussed this draft, and in particular connectivity=
 checks and secure discovery of Pref64::/n. This draft is now attempting to=
 include the ideas and comments given in the interim.

Please check this out and comment - especially on changes.

The plan is to update this according to comments and, hopefully, start WGLC=
 at the next Interim meeting.

Best regards,

        Teemu

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of ext internet-drafts@ietf.org
> Sent: 12. maaliskuuta 2012 11:40
> To: i-d-announce@ietf.org
> Cc: behave@ietf.org
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic=
-
> 06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Behavior Engineering for Hindrance
> Avoidance Working Group of the IETF.
>
>       Title           : Discovery of IPv6 Prefix Used for IPv6 Address Sy=
nthesis
>       Author(s)       : Teemu Savolainen
>                           Jouni Korhonen
>                           Dan Wing
>       Filename        : draft-ietf-behave-nat64-discovery-heuristic-06.tx=
t
>       Pages           : 14
>       Date            : 2012-03-12
>
>    This document describes a method for detecting presence of DNS64 and
>    for learning IPv6 prefix used for protocol translation on an access
>    network.  The method depends on existence of a well-known IPv4-only
>    domain name "ipv4only.arpa".  The information learned enables nodes
>    to perform local IPv6 address synthesis and to potentially avoid
>    traversal through NAT64 on dual-stack accesses and multi-interface
>    deployments.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heur=
istic-
> 06.txt
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From stephan.lagerholm@secure64.com  Mon Mar 12 07:16:01 2012
Return-Path: <stephan.lagerholm@secure64.com>
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 75E5E21E802B for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 07:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8D2CsT6JzAJ for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 07:16:00 -0700 (PDT)
Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9368A21F87D4 for <behave@ietf.org>; Mon, 12 Mar 2012 07:16:00 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 37C83B84BB; Mon, 12 Mar 2012 08:16:00 -0600 (MDT)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHnHFX-6ogmE; Mon, 12 Mar 2012 08:15:59 -0600 (MDT)
Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id E0248B849D; Mon, 12 Mar 2012 08:15:58 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1331561758; bh=+M0ygickWQzNSJXpBkckwGnrqaUTzKIlEeKTc/n9r1A=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=pOpv2Xu1Txn/U4zu1uJHg xGkRyrZzQB8xM6tsrLIGOlxZauTQcOkl8O4bGReXdNKzOnH/epdT48jAQTZBDjKnzXA MLzyzFb50MzA+RFFq9s1b6pdtCSN0bJroEj1rP8P7LNReYBsUWRXD7F3TQ4E1J5xHHa Cvar19zSO2JVAh5U=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Mar 2012 08:15:58 -0600
Message-ID: <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com>
In-Reply-To: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
Thread-Index: Ac0ANTRxb926yBqKSziKyDiihsIwigAJToDg
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com>
From: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
To: <teemu.savolainen@nokia.com>, <behave@ietf.org>
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 14:16:01 -0000

Hi Teemu and the rest of the authors,

I must be missing something but I can't see how the algorithm in section
3.1.1 is going to be secure. DNSSEC is not going to help here.

Consider the following:=20
An attacker with access to inject packets in the path between the node
and the DNS64. The attacker is have the IPv6 network 6666::/48 allocated
to him, is running an evil NAT64 box at 6666::1 where he can listen to
traffic and has registered the domain name example.com.=20
1.	Node sends a query for ipv4only.arpa. Attacker injects
6666::1.2.3.4 as the response
2.	Node sends PTR query for 6666::0. This reverse mapping is
delegated to the attacker who is the rightful owner of the IPv6 network
6666::/48. Attacker responds with evilnat64.example.com
3.	Node sends an AAAA query for evilnat64.example.com. This address
is owned by the attacker, he responds with 6666::1 + Signatures for
DNSSEC.
4.	Node performs DNSSEC validation.=20
5.	Node starts sending all traffic to the evil NAT64 box!!!

/Stephan Lagerholm

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of teemu.savolainen@nokia.com
> Sent: Monday, March 12, 2012 4:51 AM
> To: behave@ietf.org
> Subject: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
>=20
> Hi behave WG,
>=20
> In the last interim we discussed this draft, and in particular
> connectivity checks and secure discovery of Pref64::/n. This draft is
> now attempting to include the ideas and comments given in the interim.
>=20
> Please check this out and comment - especially on changes.
>=20
> The plan is to update this according to comments and, hopefully, start
> WGLC at the next Interim meeting.
>=20
> Best regards,
>=20
>         Teemu
>=20
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of ext internet-drafts@ietf.org
> > Sent: 12. maaliskuuta 2012 11:40
> > To: i-d-announce@ietf.org
> > Cc: behave@ietf.org
> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-
> heuristic-
> > 06.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Behavior Engineering for Hindrance
> > Avoidance Working Group of the IETF.
> >
> >       Title           : Discovery of IPv6 Prefix Used for IPv6
> Address Synthesis
> >       Author(s)       : Teemu Savolainen
> >                           Jouni Korhonen
> >                           Dan Wing
> >       Filename        : draft-ietf-behave-nat64-discovery-heuristic-
> 06.txt
> >       Pages           : 14
> >       Date            : 2012-03-12
> >
> >    This document describes a method for detecting presence of DNS64
> and
> >    for learning IPv6 prefix used for protocol translation on an
> access
> >    network.  The method depends on existence of a well-known IPv4-
> only
> >    domain name "ipv4only.arpa".  The information learned enables
> nodes
> >    to perform local IPv6 address synthesis and to potentially avoid
> >    traversal through NAT64 on dual-stack accesses and
multi-interface
> >    deployments.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-
> discovery-
> > heuristic-06.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-
> > 06.txt
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From stephan.lagerholm@secure64.com  Mon Mar 12 07:34:21 2012
Return-Path: <stephan.lagerholm@secure64.com>
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 DDB1221F87E0 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 07:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTS06Qtp-zxk for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 07:34:21 -0700 (PDT)
Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 248A321F87CF for <behave@ietf.org>; Mon, 12 Mar 2012 07:34:21 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id E2820B84AC; Mon, 12 Mar 2012 08:34:20 -0600 (MDT)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRFqiJU0vNTD; Mon, 12 Mar 2012 08:34:20 -0600 (MDT)
Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id B716BB849D; Mon, 12 Mar 2012 08:34:19 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1331562859; bh=C1HyFZ8OQoJNiTFe6ghrQr2wzr4Kq9pRHk30UkYtdko=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=XumVS5FaAW2q5v8URWLS5 5X+y2ACtoaRnJ5OfQ0mXGPRgZDf8Jp4xhQy+Y3kMScxeTBxpcuqm9SsJjeN9fm1M9hr W7oC3GaK6wxBzTwUJGH5EBXxZA2THsLXEqpHdUNrlT228vdIgsWSoGoJGbCVLW5EjvR 35cmoEUCDXWTd6pE=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Mar 2012 08:34:19 -0600
Message-ID: <DD056A31A84CFC4AB501BD56D1E14BBBCA9F84@exchange.secure64.com>
In-Reply-To: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
Thread-Index: Ac0ANTRxb926yBqKSziKyDiihsIwigAJrQhw
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com>
From: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
To: <teemu.savolainen@nokia.com>, <behave@ietf.org>
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 14:34:22 -0000

Hi Again,

Section '6. Exit Strategy' relies on NXDOMAIN being sent back to the
client. Note however that a lot of networks are implementing NXDOMAIN
redirect where such response is replaced with a positive response that
is redirecting the client to a portal. Relying on NXDOMAIN being sent
back is not going to be robust.=20

Additionally, as I commented earlier, the negative TTL of ipv4only.arpa
will be determined by the parents SOA setting. I don't think the
operator of .arpa is interested in changing this setting when the exit
strategy is implemented since it will affect all negative caching for
the domain.

I suggest that the exit strategy is reworked. Perhaps encode a meaning
in IP address returned by the A record or have a TXT record at
ipv4only.arpa that is either "on" or "off".

/Stephan Lagerholm

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of teemu.savolainen@nokia.com
> Sent: Monday, March 12, 2012 4:51 AM
> To: behave@ietf.org
> Subject: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
>=20
> Hi behave WG,
>=20
> In the last interim we discussed this draft, and in particular
> connectivity checks and secure discovery of Pref64::/n. This draft is
> now attempting to include the ideas and comments given in the interim.
>=20
> Please check this out and comment - especially on changes.
>=20
> The plan is to update this according to comments and, hopefully, start
> WGLC at the next Interim meeting.
>=20
> Best regards,
>=20
>         Teemu
>=20
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of ext internet-drafts@ietf.org
> > Sent: 12. maaliskuuta 2012 11:40
> > To: i-d-announce@ietf.org
> > Cc: behave@ietf.org
> > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-
> heuristic-
> > 06.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Behavior Engineering for Hindrance
> > Avoidance Working Group of the IETF.
> >
> >       Title           : Discovery of IPv6 Prefix Used for IPv6
> Address Synthesis
> >       Author(s)       : Teemu Savolainen
> >                           Jouni Korhonen
> >                           Dan Wing
> >       Filename        : draft-ietf-behave-nat64-discovery-heuristic-
> 06.txt
> >       Pages           : 14
> >       Date            : 2012-03-12
> >
> >    This document describes a method for detecting presence of DNS64
> and
> >    for learning IPv6 prefix used for protocol translation on an
> access
> >    network.  The method depends on existence of a well-known IPv4-
> only
> >    domain name "ipv4only.arpa".  The information learned enables
> nodes
> >    to perform local IPv6 address synthesis and to potentially avoid
> >    traversal through NAT64 on dual-stack accesses and
multi-interface
> >    deployments.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-
> discovery-
> > heuristic-06.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-
> > 06.txt
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From dwing@cisco.com  Mon Mar 12 08:09:47 2012
Return-Path: <dwing@cisco.com>
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 02A3621F8781 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 08:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.945
X-Spam-Level: 
X-Spam-Status: No, score=-108.945 tagged_above=-999 required=5 tests=[AWL=1.654, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h4I5mxWu0+M for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 08:09:46 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9C21F8773 for <behave@ietf.org>; Mon, 12 Mar 2012 08:09:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5292; q=dns/txt; s=iport; t=1331564986; x=1332774586; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=SjjlejlAFfcJV4egxoUhWzreqzMe76fUvXUlazIDm9U=; b=FdADAzYhu05pSiA3h+modIIGDCRBqe3Nsg1Y512eoxgekJ5v7avk3/6L PJsvhfm+KIX4kKS/05eDSi/3i4VYGcDJGJRWfvlB9fSVy5czJ7aNThf27 RQfwo2yWoQJlY7wWSKFBuQHkQdVvAF5JPG1wq6D7YpA9XASbFBWV4w8cS w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADkRXk+rRDoG/2dsb2JhbABDpW6PZ4EHggkBAQEEAQEBBQoBFQIQMwEXAQMCCQ8CBAEBKAcZDhUKCQgBAQQBEgkCF4VvgXgMnRYBnmWRAQSIVIUPmAyDA4E2BhE
X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="35742996"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 12 Mar 2012 15:09:44 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2CF9iAA001826; Mon, 12 Mar 2012 15:09:44 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Stephan Lagerholm'" <stephan.lagerholm@secure64.com>, <teemu.savolainen@nokia.com>, <behave@ietf.org>
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com> <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com>
In-Reply-To: <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com>
Date: Mon, 12 Mar 2012 08:09:43 -0700
Message-ID: <000001cd0062$2852ea50$78f8bef0$@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: Ac0ANTRxb926yBqKSziKyDiihsIwigAJToDgAAGT4mA=
Content-Language: en-us
Subject: Re: [BEHAVE] New	revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 15:09:47 -0000

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Stephan Lagerholm
> Sent: Monday, March 12, 2012 7:16 AM
> To: teemu.savolainen@nokia.com; behave@ietf.org
> Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
> 
> Hi Teemu and the rest of the authors,
> 
> I must be missing something but I can't see how the algorithm in
> section
> 3.1.1 is going to be secure. DNSSEC is not going to help here.
> 
> Consider the following:
> An attacker with access to inject packets in the path between the node
> and the DNS64. The attacker is have the IPv6 network 6666::/48
> allocated
> to him, is running an evil NAT64 box at 6666::1 where he can listen to
> traffic and has registered the domain name example.com.
> 1.	Node sends a query for ipv4only.arpa. Attacker injects
> 6666::1.2.3.4 as the response
> 2.	Node sends PTR query for 6666::0. This reverse mapping is
> delegated to the attacker who is the rightful owner of the IPv6 network
> 6666::/48. Attacker responds with evilnat64.example.com
> 3.	Node sends an AAAA query for evilnat64.example.com. This address
> is owned by the attacker, he responds with 6666::1 + Signatures for
> DNSSEC.
> 4.	Node performs DNSSEC validation.
> 5.	Node starts sending all traffic to the evil NAT64 box!!!

The step missing is that the host needs a list of authorized domain
names.  So, for example, a Comcast subscriber would have comcast.net 
on their list of authorized domain names.  If they take that computer
and visit a Starbucks coffee shop, they would be confronted with a 
domain name other than comcast.net (e.g., "example.com" from your
above attack scenario) -- somewhat akin to what happens, today, with
choosing which of the dozens of SSIDs are "valid" when visiting a
Starbucks.

The need for this pre-configured list of authorized domain names
is certainly not a good aspect of the DNSSEC scheme.  But it is
necessary to prevent the very attack you describe.

-d


> /Stephan Lagerholm
> 
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of teemu.savolainen@nokia.com
> > Sent: Monday, March 12, 2012 4:51 AM
> > To: behave@ietf.org
> > Subject: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> > heuristic-06.txt
> >
> > Hi behave WG,
> >
> > In the last interim we discussed this draft, and in particular
> > connectivity checks and secure discovery of Pref64::/n. This draft is
> > now attempting to include the ideas and comments given in the
> interim.
> >
> > Please check this out and comment - especially on changes.
> >
> > The plan is to update this according to comments and, hopefully,
> start
> > WGLC at the next Interim meeting.
> >
> > Best regards,
> >
> >         Teemu
> >
> > > -----Original Message-----
> > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > > Behalf Of ext internet-drafts@ietf.org
> > > Sent: 12. maaliskuuta 2012 11:40
> > > To: i-d-announce@ietf.org
> > > Cc: behave@ietf.org
> > > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-
> > heuristic-
> > > 06.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Behavior Engineering for Hindrance
> > > Avoidance Working Group of the IETF.
> > >
> > >       Title           : Discovery of IPv6 Prefix Used for IPv6
> > Address Synthesis
> > >       Author(s)       : Teemu Savolainen
> > >                           Jouni Korhonen
> > >                           Dan Wing
> > >       Filename        : draft-ietf-behave-nat64-discovery-
> heuristic-
> > 06.txt
> > >       Pages           : 14
> > >       Date            : 2012-03-12
> > >
> > >    This document describes a method for detecting presence of DNS64
> > and
> > >    for learning IPv6 prefix used for protocol translation on an
> > access
> > >    network.  The method depends on existence of a well-known IPv4-
> > only
> > >    domain name "ipv4only.arpa".  The information learned enables
> > nodes
> > >    to perform local IPv6 address synthesis and to potentially avoid
> > >    traversal through NAT64 on dual-stack accesses and
> multi-interface
> > >    deployments.
> > >
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-
> > discovery-
> > > heuristic-06.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > This Internet-Draft can be retrieved at:
> > >
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> > heuristic-
> > > 06.txt
> > >
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > https://www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave


From ssenthil@cisco.com  Mon Mar 12 08:11:53 2012
Return-Path: <ssenthil@cisco.com>
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 47EDF21F8794 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 08:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.98
X-Spam-Level: 
X-Spam-Status: No, score=-8.98 tagged_above=-999 required=5 tests=[AWL=1.619,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eALuZs01cVXB for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 08:11:52 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 76A8021F8781 for <behave@ietf.org>; Mon, 12 Mar 2012 08:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=3969; q=dns/txt; s=iport; t=1331565112; x=1332774712; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=aPSTtkeoxNWA56XAb+0LPbvE5MXlJtZonXmQctHNtNQ=; b=koSh03De738NUsNrmUP2TOnYZ/EwtUVPhHdSsX90+EZbFUJ+gNmXt3DL TaB+t4z5Ov1k1lhUk8aYRTiomOBMHQog6ULW2diB0uw5geVj5QYzspuPJ xzBZc6aa5sSkiianUZoqjPMKWb7e65P7qOAeNxvrxtfVt+8oF7/5x//+z Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGsRXk+rRDoG/2dsb2JhbABDtVWBB4IJAQEBAwEBAQEPAScCATEQDQEICQVZBjABAQQBEhQFCYdjBAELnRcBnmWJRIc9BIhUhSSHVIsrhHiDAQ
X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="35622559"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 12 Mar 2012 15:11:52 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2CFBquU003841; Mon, 12 Mar 2012 15:11:52 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 08:11:52 -0700
Received: from 10.150.24.246 ([10.150.24.246]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 12 Mar 2012 15:11:51 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Mar 2012 11:11:49 -0500
From: ssenthil <ssenthil@cisco.com>
To: Cameron Byrne <cb.list6@gmail.com>, <behave@ietf.org>
Message-ID: <CB838A75.2490F%ssenthil@cisco.com>
Thread-Topic: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
Thread-Index: Ac0AYnJqKvvf74tT90+utgHwrgafmw==
In-Reply-To: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Mar 2012 15:11:52.0046 (UTC) FILETIME=[743B70E0:01CD0062]
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 15:11:53 -0000

Thanks for your comments, please see inline.


On 3/10/12 8:50 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

> Citing some RIR policy
> 
> 
http://www.apnic.net/community/ipv4-exhaustion/exhaustion-and-network-operator>
s
> 
> http://www.ripe.net/ripe/docs/ripe-530#----use-of-last-/8-for-pa-allocations
> 
> The 2 above policies, already in force in APNIC and soon to be in
> force in RIPE, say a new entrant can only get a /22, 1,024 IPv4
> addresses
> 
> Trying to keep the math simple here, 64,000 available ports * 1024
> IPv4 addresses = 65.5 million sessions.  Just as one data point, i
> cannot run my network on this allocation, assuming i put 100% of the
> allocation to CGN use.
> 
> This brings me to my questions about the draft, it states:
> 
> "While it is tempting to maximize the return on the investment by
>    maximizing the use of the existing IPv4 addresses, doing End point
>    dependent mapping, the harmful effects of this overrides any benefits
>    that it offers."
> 
> Can this be quantified?  It sounds a bit hand wavy to me.  Especially
> since you are essentially saying that there is NO business case for
> any new entrant to enter the IPv4 large service provider space, since
> EIM is required and IPv4 allocations to support EIM are not available
> at large scale.   Does this make sense
> 

I am not sure what do you mean by quantifying here, quantifying the number
of applications that would break? The business case has always been there,
not just today and there are several NAT implementations that does this.
But that did not deter IETF from making the statement in RFC4787 to say that
it should not be used.


> Next
> 
> "Peer to Peer applications are becoming very common and some real life
>    examples of P2P applications are SIP used by VoIP service providers,
>    instant messaging, voice and video chat, Google Talk, Apple Facetime
>    and several famous gaming applications.  The notion of not supporting
>    P2P applications is not just practical and NATs MUST be designed to
>    facilitate these applications."
> 
> You are equating things that are not equals. Correct, some variations
> of SIP do not work without ALGs in EDM NATs.  But, ALGs do make some
> protocols work, like some types of SIP (there are too many types of
> SIP to make broad statements).  Separately, it is my experience that
> various video chat applications like Google Talk work across EDM NATs
> without ALGs, ...same with Skype and other so called p2p applications.
> 
> So, you may want to change the language above to be more specific
> about what exactly breaks and why... and avoid painting with a broad
> brush .... and avoid listing applications that DO work with EDM like
> Google Talk (yes, relays are used... but the important thing is the
> service works for the customer)
> 

So you would like to see specific examples on what apps break and why,
as opposed to listing all the P2P apps? I can collect some specifics and add
it to the draft. If you use relays in between that is not truly P2P, same
thing with ALGs.

> Overall, i am opposed to this draft saying EDM is harmful, you are

RFC 4787 has already said dependent mappings are bad and should not be used,
but it doesn't go into the details on why it is bad. That is the intention
of this draft. 

> better off saying IPv4 exhaustion is harmful.  EDM is quite common
> today.  Saying EDM is bad is not helpful, but a technical discussion
> about pros and cons of EIM and EDM would be helpful.  There will be
> more pressure to use EDM as IPv4 exhaustion intensifies.
> 
IETF has taken a position to discourage any techniques that would prolong
the life of IPv4 and EDM does exactly that and in the process breaks apps.

Senthil

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


From cb.list6@gmail.com  Mon Mar 12 09:33:53 2012
Return-Path: <cb.list6@gmail.com>
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 4458011E808D for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 09:33:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.453
X-Spam-Level: 
X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQTQdxhtuhNK for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 09:33:48 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 220A721F875A for <behave@ietf.org>; Mon, 12 Mar 2012 09:33:48 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so3137942yhp.31 for <behave@ietf.org>; Mon, 12 Mar 2012 09:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gWYBBakL+NJ4pK26tjVWi2XzUI8pLC/FEcNIGG65Gw8=; b=uq7sbHygf5EvWI04Um76u2jUAwB05mGYiqmXjlI0Xu1ca/42cuUF1w3e6XN51kA97e 6oztni4jS9kKoplxhrtz/gP78xmq6Zd1qdWRs4WfAsuLwjXMWlQMHuzev3rCs56rfxYC dXl9IOEVSuEayyEPgR2cfdWj3GD/ksNicbaLlf62LOLguB9a7CaSBwPXpMKdtuw4kTGT i8RpCbc3loH/h6HP48uUc3TYMCVtfcUKFFyfplBEVikViTgqRnawjiBhcERkOOJbgiaS Zg3Nfou3kZ4WNn25ty8RDqOI+WFE4k6LY9GqLmIa3Ckj0aYP74hT2RmBpjr/2/iLsJOD arrw==
MIME-Version: 1.0
Received: by 10.68.195.199 with SMTP id ig7mr8515650pbc.81.1331570027365; Mon, 12 Mar 2012 09:33:47 -0700 (PDT)
Received: by 10.142.163.16 with HTTP; Mon, 12 Mar 2012 09:33:47 -0700 (PDT)
In-Reply-To: <CB838A75.2490F%ssenthil@cisco.com>
References: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com> <CB838A75.2490F%ssenthil@cisco.com>
Date: Mon, 12 Mar 2012 09:33:47 -0700
Message-ID: <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: ssenthil <ssenthil@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 16:33:53 -0000

Hi,

In line.

On Mon, Mar 12, 2012 at 9:11 AM, ssenthil <ssenthil@cisco.com> wrote:
> Thanks for your comments, please see inline.
>
>
> On 3/10/12 8:50 AM, "Cameron Byrne" <cb.list6@gmail.com> wrote:
>
>> Citing some RIR policy
>>
>>
> http://www.apnic.net/community/ipv4-exhaustion/exhaustion-and-network-ope=
rator>
> s
>>
>> http://www.ripe.net/ripe/docs/ripe-530#----use-of-last-/8-for-pa-allocat=
ions
>>
>> The 2 above policies, already in force in APNIC and soon to be in
>> force in RIPE, say a new entrant can only get a /22, 1,024 IPv4
>> addresses
>>
>> Trying to keep the math simple here, 64,000 available ports * 1024
>> IPv4 addresses =3D 65.5 million sessions. =A0Just as one data point, i
>> cannot run my network on this allocation, assuming i put 100% of the
>> allocation to CGN use.
>>
>> This brings me to my questions about the draft, it states:
>>
>> "While it is tempting to maximize the return on the investment by
>> =A0 =A0maximizing the use of the existing IPv4 addresses, doing End poin=
t
>> =A0 =A0dependent mapping, the harmful effects of this overrides any bene=
fits
>> =A0 =A0that it offers."
>>
>> Can this be quantified? =A0It sounds a bit hand wavy to me. =A0Especiall=
y
>> since you are essentially saying that there is NO business case for
>> any new entrant to enter the IPv4 large service provider space, since
>> EIM is required and IPv4 allocations to support EIM are not available
>> at large scale. =A0 Does this make sense
>>
>
> I am not sure what do you mean by quantifying here, quantifying the numbe=
r
> of applications that would break? The business case has always been there=
,
> not just today and there are several NAT implementations that does this.
> But that did not deter IETF from making the statement in RFC4787 to say t=
hat
> it should not be used.
>

You said in the draft that EDM's negative characteristics exceed the
positive attributes of maximizing address use with EDM and port
overloading.  Thus, everyone should use EIM.

I said in my email, it is not possible to run a large network on a /22
with EIM, and a /22 is all that a new entrant may get from an RIR per
policy today in APNIC and soon in RIPE.  I think ARIN has a similar
plan, but i have not seen it.

Thus, i do not think it is beneficial for the IETF to say EDM and port
overloading are harmful or that EIM is a better "return on
investment",   when it may be the only way to provide IPv4 service for
new entrants.   My stance is that your assertion is wrong, the ability
to compete and offer commercial service using EDM is superior than not
offering service at all.  Thus, EDM exceeds that value of EIM (not
offering service).  Saying EDM is harmful is negative statement to
network operators that use it today (many do) and explicitly hurts new
entrants that must use EDM and port overloading to offer legacy IPv4
service.

Saying EDM is harmful and publishing in the IETF does not achieve
anything in the real world, the only thing it does is confuse people
who read and think EDM is an obviously unjustified path (the IETF said
so ...) and design protocols and applications that assume EDM is not
there, when it fact it is.  And, my guess is that EDM use will
increase given the constraints on IPv4 space.

Your time is better spent writing a draft on how applications can
better work in an EDM network, since that is the direction the
internet is going (more ipv4 constraints)

>
>> Next
>>
>> "Peer to Peer applications are becoming very common and some real life
>> =A0 =A0examples of P2P applications are SIP used by VoIP service provide=
rs,
>> =A0 =A0instant messaging, voice and video chat, Google Talk, Apple Facet=
ime
>> =A0 =A0and several famous gaming applications. =A0The notion of not supp=
orting
>> =A0 =A0P2P applications is not just practical and NATs MUST be designed =
to
>> =A0 =A0facilitate these applications."
>>
>> You are equating things that are not equals. Correct, some variations
>> of SIP do not work without ALGs in EDM NATs. =A0But, ALGs do make some
>> protocols work, like some types of SIP (there are too many types of
>> SIP to make broad statements). =A0Separately, it is my experience that
>> various video chat applications like Google Talk work across EDM NATs
>> without ALGs, ...same with Skype and other so called p2p applications.
>>
>> So, you may want to change the language above to be more specific
>> about what exactly breaks and why... and avoid painting with a broad
>> brush .... and avoid listing applications that DO work with EDM like
>> Google Talk (yes, relays are used... but the important thing is the
>> service works for the customer)
>>
>
> So you would like to see specific examples on what apps break and why,
> as opposed to listing all the P2P apps? I can collect some specifics and =
add
> it to the draft. If you use relays in between that is not truly P2P, same
> thing with ALGs.
>

Right, explain to me why this draft is needed?  Explain which
applications break on an EDM network that do not break on an EIM
network.

P2P is an overloaded term, and therefore does not mean anything in
this technical context. Saying pure P2P does not work in an EDM
network may be correct, but saying Google Talk or Skype or BitTorrent
does not work on an EDM network is wrong.  They do work.


>> Overall, i am opposed to this draft saying EDM is harmful, you are
>
> RFC 4787 has already said dependent mappings are bad and should not be us=
ed,
> but it doesn't go into the details on why it is bad. That is the intentio=
n
> of this draft.
>
>> better off saying IPv4 exhaustion is harmful. =A0EDM is quite common
>> today. =A0Saying EDM is bad is not helpful, but a technical discussion
>> about pros and cons of EIM and EDM would be helpful. =A0There will be
>> more pressure to use EDM as IPv4 exhaustion intensifies.
>>
> IETF has taken a position to discourage any techniques that would prolong
> the life of IPv4 and EDM does exactly that and in the process breaks apps=
.
>

Great. The IETF made another short sighted declaration to justify the
use of tools like STUN.  That promulgation by the IETF in RFC4786 was
rejected by hardware/software implementors and network operators who
made EDM gear and deployed it.  So, now you want the IETF to say EDM
is bad again, now that there is even less evidence or motivation that
the suggestion will be listened to?

I am all for highlighting the technical ins and outs so everyone
understand the operations of various network functions, but "harmful"
drafts are like lightening rods.   Especially when all the available
evidence shows that, on the real internet, EDM is helpful to network
operators... and they are the ones that buy and deploy CGNs.

CB

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

From simon.perreault@viagenie.ca  Mon Mar 12 10:47:37 2012
Return-Path: <simon.perreault@viagenie.ca>
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 9706921F89A3 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 10:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level: 
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRL2MH8e2vp4 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 10:47:22 -0700 (PDT)
Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 861A221F8997 for <behave@ietf.org>; Mon, 12 Mar 2012 10:47:22 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:e8e7:7c89:37f8:3721]) by blues.viagenie.ca (Postfix) with ESMTPSA id 3BED11C25C; Mon, 12 Mar 2012 13:47:21 -0400 (EDT)
Message-ID: <4F5E36A8.5000304@viagenie.ca>
Date: Mon, 12 Mar 2012 13:47:20 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Cameron Byrne <cb.list6@gmail.com>
References: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com> <CB838A75.2490F%ssenthil@cisco.com> <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com>
In-Reply-To: <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 17:47:37 -0000

One aspect of EDM that may have an impact on large operators is logging.

(Assuming you need to log...)

With EIM you only need to log internal<->external port mappings. If 
allocation is done semi-statically or in port blocks then this is fairly 
efficient.

With EDM you need to log every single connection. And for every single 
connection you additionally need to log the destination address and port 
(this is not necessary with EIM). So we're talking about a *lot* more 
data to be logged.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From cb.list6@gmail.com  Mon Mar 12 10:56:12 2012
Return-Path: <cb.list6@gmail.com>
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 28D7111E808A for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 10:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.455
X-Spam-Level: 
X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3vcmBUCHMgN for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 10:56:11 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDCE11E8089 for <behave@ietf.org>; Mon, 12 Mar 2012 10:56:11 -0700 (PDT)
Received: by dakl33 with SMTP id l33so5890484dak.31 for <behave@ietf.org>; Mon, 12 Mar 2012 10:56:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wlUF8fJssGCJnYNSMGh5STYuxfZxVmCXQ/P4xbDaaHc=; b=hbxuPSS1XzvA/jgupHU3Zk2XnZ7m0oMSDbpjwlqWojCsoN3+qR+FMqmAmbynTDNyfG ZmUm8c/g+175HaO/zSDHp4I90mBYRJAuiAsREG/gYkuQB0UJj9sxLwLdjryPvyPP5cdB XnqvNyJ0B3ski7IxOBstD5/UGMuktHJG+QzMGxnA781AP0yjFr7uMkroC74aK440LXYO q2fLI33kd25lis2ro8oTzXiFHireJb763UNYyhYCwFEQHTDvkXF4gcsh74qxUe9UuauP XqgraS4apfrAd6PNDP/1aUWZgRReDyFoPJVv6mEXywlKTHNnPqh8UyeLwg7hk1aKPA14 QVfQ==
MIME-Version: 1.0
Received: by 10.68.129.100 with SMTP id nv4mr2246691pbb.109.1331574971253; Mon, 12 Mar 2012 10:56:11 -0700 (PDT)
Received: by 10.142.163.16 with HTTP; Mon, 12 Mar 2012 10:56:11 -0700 (PDT)
In-Reply-To: <4F5E36A8.5000304@viagenie.ca>
References: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com> <CB838A75.2490F%ssenthil@cisco.com> <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com> <4F5E36A8.5000304@viagenie.ca>
Date: Mon, 12 Mar 2012 10:56:11 -0700
Message-ID: <CAD6AjGTnKL3cM4nj+TDfcJPvSeaSsNkD_Tm_=ZnY_bQ6yYgj0Q@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 17:56:12 -0000

On Mon, Mar 12, 2012 at 10:47 AM, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> One aspect of EDM that may have an impact on large operators is logging.
>
> (Assuming you need to log...)
>
> With EIM you only need to log internal<->external port mappings. If
> allocation is done semi-statically or in port blocks then this is fairly
> efficient.
>
> With EDM you need to log every single connection. And for every single
> connection you additionally need to log the destination address and port
> (this is not necessary with EIM). So we're talking about a *lot* more dat=
a
> to be logged.
>

That is closer to a quantification, but still far from justification
as "harmfull"

EIM is a lot more logging than stateless, but no need to say EIM is harmful=
.

In any case, there are tradeoffs.  I assume the harmful title means
that with X there is no way the tradeoffs make sense or that X is
fundamentally flawed.

I don't believe that case has been made here.

CB
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
> STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Mon Mar 12 11:20:53 2012
Return-Path: <simon.perreault@viagenie.ca>
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 2750321F87FE for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 11:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWfjCL+vycXB for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 11:20:52 -0700 (PDT)
Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7343121F87E0 for <behave@ietf.org>; Mon, 12 Mar 2012 11:20:52 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:e8e7:7c89:37f8:3721]) by blues.viagenie.ca (Postfix) with ESMTPSA id 3462A1C20F; Mon, 12 Mar 2012 14:20:51 -0400 (EDT)
Message-ID: <4F5E3E81.8080603@viagenie.ca>
Date: Mon, 12 Mar 2012 14:20:49 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Cameron Byrne <cb.list6@gmail.com>
References: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com> <CB838A75.2490F%ssenthil@cisco.com> <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com> <4F5E36A8.5000304@viagenie.ca> <CAD6AjGTnKL3cM4nj+TDfcJPvSeaSsNkD_Tm_=ZnY_bQ6yYgj0Q@mail.gmail.com>
In-Reply-To: <CAD6AjGTnKL3cM4nj+TDfcJPvSeaSsNkD_Tm_=ZnY_bQ6yYgj0Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 18:20:53 -0000

On 2012-03-12 13:56, Cameron Byrne wrote:
> On Mon, Mar 12, 2012 at 10:47 AM, Simon Perreault
> <simon.perreault@viagenie.ca>  wrote:
>> One aspect of EDM that may have an impact on large operators is logging.
>
> That is closer to a quantification, but still far from justification
> as "harmfull"

I'm not trying to justify the "harmful" qualifier, I'm trying to expose 
a disadvantage of EDM to which you might be sensitive.

In any case, the "harmful" qualifier would be derived from the harm EDM 
causes to the Internet, not to some ISPs' operations department.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From teemu.savolainen@nokia.com  Mon Mar 12 11:46:47 2012
Return-Path: <teemu.savolainen@nokia.com>
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 CA00B21F89B2 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 11:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.531
X-Spam-Level: 
X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=2.068,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMO0ixRTwCpb for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 11:46:46 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A16C521F89AC for <behave@ietf.org>; Mon, 12 Mar 2012 11:46:45 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2CIkCNk019888; Mon, 12 Mar 2012 20:46:42 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 20:46:26 +0200
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Mon, 12 Mar 2012 19:46:25 +0100
From: <teemu.savolainen@nokia.com>
To: <stephan.lagerholm@secure64.com>, <behave@ietf.org>
Thread-Topic: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
Thread-Index: AQHNAIBt5JBrb8DIWk6q2CDHj1CJIg==
Date: Mon, 12 Mar 2012 18:46:25 +0000
Message-ID: <916CE6CF87173740BC8A2CE443096962042F4F17@008-AM1MPN1-053.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com> <DD056A31A84CFC4AB501BD56D1E14BBBCA9F84@exchange.secure64.com>
In-Reply-To: <DD056A31A84CFC4AB501BD56D1E14BBBCA9F84@exchange.secure64.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7InS4bkyy1NyMvQvnfS8p8RDUwo4BYy7JeAypGlqoE8L508UHXLwj4zVFZp7SVzD6u96Ii5sEHHUmgxS1Q2zZMgZlnU4+KA+gjD9TGuj2Nj4537A5r/YAIJTEpQ1EcmtulNEWTiNY7JPy71vnbBn1AXnSd/cdUMCgIhWYsg/aWvNH68GymGSwkwbKaahVT/V7V6neFcN31w00pL1nWULhiAj7dtsL/mjC5KaiwGgw+km7zVF1uyrK6J+GC3JnpAQruR9bYWzNC83Jt6z0TrEEBD0=
x-originating-ip: [10.162.86.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2012 18:46:26.0363 (UTC) FILETIME=[6DEC50B0:01CD0080]
X-Nokia-AV: Clean
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 18:46:47 -0000

Hi Stephan,

Thank you for your comments. I'm thinking about the security comment still.

If the node would have validating resolver, it would not fall into that tra=
p.

Also the node could have this configured off, as said in the end of section=
 6. Exit strategy.

But... Maybe an address from the 192.0.0.0/24 space could be selected for t=
his "off" indication? (http://www.iana.org/assignments/iana-ipv4-special-re=
gistry/iana-ipv4-special-registry.xml)?

I don't like the TXT record, as it would require additional query.

Best regards,

	Teemu



> -----Original Message-----
> From: ext Stephan Lagerholm [mailto:stephan.lagerholm@secure64.com]
> Sent: 12. maaliskuuta 2012 16:34
> To: Savolainen Teemu (Nokia-NRC/Tampere); behave@ietf.org
> Subject: RE: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
>=20
> Hi Again,
>=20
> Section '6. Exit Strategy' relies on NXDOMAIN being sent back to the clie=
nt.
> Note however that a lot of networks are implementing NXDOMAIN redirect
> where such response is replaced with a positive response that is redirect=
ing
> the client to a portal. Relying on NXDOMAIN being sent back is not going =
to
> be robust.
>=20
> Additionally, as I commented earlier, the negative TTL of ipv4only.arpa w=
ill
> be determined by the parents SOA setting. I don't think the operator of .=
arpa
> is interested in changing this setting when the exit strategy is implemen=
ted
> since it will affect all negative caching for the domain.
>=20
> I suggest that the exit strategy is reworked. Perhaps encode a meaning in=
 IP
> address returned by the A record or have a TXT record at ipv4only.arpa th=
at
> is either "on" or "off".
>=20
> /Stephan Lagerholm
>=20
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of teemu.savolainen@nokia.com
> > Sent: Monday, March 12, 2012 4:51 AM
> > To: behave@ietf.org
> > Subject: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> > heuristic-06.txt
> >
> > Hi behave WG,
> >
> > In the last interim we discussed this draft, and in particular
> > connectivity checks and secure discovery of Pref64::/n. This draft is
> > now attempting to include the ideas and comments given in the interim.
> >
> > Please check this out and comment - especially on changes.
> >
> > The plan is to update this according to comments and, hopefully, start
> > WGLC at the next Interim meeting.
> >
> > Best regards,
> >
> >         Teemu
> >
> > > -----Original Message-----
> > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > > Behalf Of ext internet-drafts@ietf.org
> > > Sent: 12. maaliskuuta 2012 11:40
> > > To: i-d-announce@ietf.org
> > > Cc: behave@ietf.org
> > > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-
> > heuristic-
> > > 06.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Behavior Engineering for Hindrance
> > > Avoidance Working Group of the IETF.
> > >
> > >       Title           : Discovery of IPv6 Prefix Used for IPv6
> > Address Synthesis
> > >       Author(s)       : Teemu Savolainen
> > >                           Jouni Korhonen
> > >                           Dan Wing
> > >       Filename        : draft-ietf-behave-nat64-discovery-heuristic-
> > 06.txt
> > >       Pages           : 14
> > >       Date            : 2012-03-12
> > >
> > >    This document describes a method for detecting presence of DNS64
> > and
> > >    for learning IPv6 prefix used for protocol translation on an
> > access
> > >    network.  The method depends on existence of a well-known IPv4-
> > only
> > >    domain name "ipv4only.arpa".  The information learned enables
> > nodes
> > >    to perform local IPv6 address synthesis and to potentially avoid
> > >    traversal through NAT64 on dual-stack accesses and
> multi-interface
> > >    deployments.
> > >
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-
> > discovery-
> > > heuristic-06.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > This Internet-Draft can be retrieved at:
> > >
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> > heuristic-
> > > 06.txt
> > >
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > https://www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave

From simon.perreault@viagenie.ca  Mon Mar 12 12:55:52 2012
Return-Path: <simon.perreault@viagenie.ca>
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 E586721E80C3 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 12:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Svz1ByKMOlM for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 12:55:51 -0700 (PDT)
Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8430A21E80B9 for <behave@ietf.org>; Mon, 12 Mar 2012 12:55:50 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:e8e7:7c89:37f8:3721]) by blues.viagenie.ca (Postfix) with ESMTPSA id AC8911C20F for <behave@ietf.org>; Mon, 12 Mar 2012 15:55:49 -0400 (EDT)
Message-ID: <4F5E54C5.7080509@viagenie.ca>
Date: Mon, 12 Mar 2012 15:55:49 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: behave@ietf.org
References: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com> <CB838A75.2490F%ssenthil@cisco.com> <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com> <4F5E36A8.5000304@viagenie.ca>
In-Reply-To: <4F5E36A8.5000304@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 19:55:53 -0000

On 2012-03-12 13:47, Simon Perreault wrote:
> One aspect of EDM that may have an impact on large operators is logging.

Correction: this is an aspect of EDM *with port overloading*. Not all 
EDM NATs do port overloading, so we have to be precise.

Simon

> (Assuming you need to log...)
>
> With EIM you only need to log internal<->external port mappings. If
> allocation is done semi-statically or in port blocks then this is fairly
> efficient.
>
> With EDM you need to log every single connection. And for every single
> connection you additionally need to log the destination address and port
> (this is not necessary with EIM). So we're talking about a *lot* more
> data to be logged.

-- 
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 ovautrin@juniper.net  Mon Mar 12 13:34:28 2012
Return-Path: <ovautrin@juniper.net>
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 6B3A011E80AB for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 13:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRBKxNdauGrQ for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 13:34:27 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2633A11E80A0 for <behave@ietf.org>; Mon, 12 Mar 2012 13:34:27 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT15dxvf0ehuOHIX8ZSHdK3UrPJLooKGZ@postini.com; Mon, 12 Mar 2012 13:34:27 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 12 Mar 2012 13:33:20 -0700
From: Olivier Vautrin <ovautrin@juniper.net>
To: ssenthil <ssenthil@cisco.com>, Cameron Byrne <cb.list6@gmail.com>, "behave@ietf.org" <behave@ietf.org>
Date: Mon, 12 Mar 2012 13:33:19 -0700
Thread-Topic: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
Thread-Index: Ac0Aj1x+wHrDLawHRkGpEgwdjet04w==
Message-ID: <CB83AB05.3762F%ovautrin@juniper.net>
In-Reply-To: <CB838A75.2490F%ssenthil@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 20:34:28 -0000

It is possible to mix EIM and EDM on the same CGN. You can have EDM for
HTTP and DNS request and EIM for the rest for example. So I don't think
the general comment "EDM breaks application" is true as you can activate
it only on applications that doesn't break.

/Olivier

On 3/12/12 9:11 AM, "ssenthil" <ssenthil@cisco.com> wrote:

>
>I am not sure what do you mean by quantifying here, quantifying the number
>of applications that would break? The business case has always been there,
>not just today and there are several NAT implementations that does this.
>But that did not deter IETF from making the statement in RFC4787 to say
>that
>it should not be used.


From marka@isc.org  Mon Mar 12 14:29:18 2012
Return-Path: <marka@isc.org>
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 693D311E80F2 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level: 
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGsCg35QHO4M for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:29:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9817411E8118 for <behave@ietf.org>; Mon, 12 Mar 2012 14:29:17 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6B6ACC9424; Mon, 12 Mar 2012 21:29:04 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7c2f:c400:f438:c0b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 28368216C31; Mon, 12 Mar 2012 21:29:04 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0E1C61E68961; Tue, 13 Mar 2012 08:28:58 +1100 (EST)
To: "Dan Wing" <dwing@cisco.com>
From: Mark Andrews <marka@isc.org>
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com> <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com> <000001cd0062$2852ea50$78f8bef0$@com>
In-reply-to: Your message of "Mon, 12 Mar 2012 08:09:43 PDT." <000001cd0062$2852ea50$78f8bef0$@com>
Date: Tue, 13 Mar 2012 08:28:57 +1100
Message-Id: <20120312212858.0E1C61E68961@drugs.dv.isc.org>
Cc: behave@ietf.org, 'Stephan Lagerholm' <stephan.lagerholm@secure64.com>
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 21:29:18 -0000

In message <000001cd0062$2852ea50$78f8bef0$@com>, "Dan Wing" writes:
> > -----Original Message-----
> > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > Behalf Of Stephan Lagerholm
> > Sent: Monday, March 12, 2012 7:16 AM
> > To: teemu.savolainen@nokia.com; behave@ietf.org
> > Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> > heuristic-06.txt
> > 
> > Hi Teemu and the rest of the authors,
> > 
> > I must be missing something but I can't see how the algorithm in
> > section
> > 3.1.1 is going to be secure. DNSSEC is not going to help here.
> > 
> > Consider the following:
> > An attacker with access to inject packets in the path between the node
> > and the DNS64. The attacker is have the IPv6 network 6666::/48
> > allocated
> > to him, is running an evil NAT64 box at 6666::1 where he can listen to
> > traffic and has registered the domain name example.com.
> > 1.	Node sends a query for ipv4only.arpa. Attacker injects
> > 6666::1.2.3.4 as the response
> > 2.	Node sends PTR query for 6666::0. This reverse mapping is
> > delegated to the attacker who is the rightful owner of the IPv6 network
> > 6666::/48. Attacker responds with evilnat64.example.com
> > 3.	Node sends an AAAA query for evilnat64.example.com. This address
> > is owned by the attacker, he responds with 6666::1 + Signatures for
> > DNSSEC.
> > 4.	Node performs DNSSEC validation.
> > 5.	Node starts sending all traffic to the evil NAT64 box!!!
> 
> The step missing is that the host needs a list of authorized domain
> names.  So, for example, a Comcast subscriber would have comcast.net 
> on their list of authorized domain names.  If they take that computer
> and visit a Starbucks coffee shop, they would be confronted with a 
> domain name other than comcast.net (e.g., "example.com" from your
> above attack scenario) -- somewhat akin to what happens, today, with
> choosing which of the dozens of SSIDs are "valid" when visiting a
> Starbucks.
> 
> The need for this pre-configured list of authorized domain names
> is certainly not a good aspect of the DNSSEC scheme.  But it is
> necessary to prevent the very attack you describe.

So basically no security as the method also needs to work at Starbucks.
 
> -d
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ssenthil@cisco.com  Mon Mar 12 14:30:35 2012
Return-Path: <ssenthil@cisco.com>
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 BFFBA11E813E for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level: 
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[AWL=1.349,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgaJH8A-kAlU for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:30:35 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0466611E80FC for <behave@ietf.org>; Mon, 12 Mar 2012 14:30:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=4308; q=dns/txt; s=iport; t=1331587835; x=1332797435; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=5yDkVK113ugrDSR+7zHXbqM0yX74274o+L0TVtaqqNA=; b=I3TCWufXMapKNoIWYYTTDZLQ9hty7hVBR5SRnuXkRVehGQk+uVD7k1wV QQq7l7LgMAA7tMt/awwwzkA/phb7ZFfOdCRSHcMlOdy7uE0oq2xrVVeso 2bYWyJ3jBRYWVZSq6bgldvpaJ1G//bc0StEwhaYSMvd2IbUb3dW1t7nkS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIRqXk+rRDoH/2dsb2JhbABDtVSBB4IJAQEBAwEBAQELBAEnAgEoBQQLBQ0BCAkFXzABAQQOBRkJh2MEAQudFAGeegSRAQSIVIUkh1SQI4MBgT4
X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="35682424"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 12 Mar 2012 21:30:35 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CLUXXo024768; Mon, 12 Mar 2012 21:30:34 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 14:30:33 -0700
Received: from 10.117.198.135 ([10.117.198.135]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 12 Mar 2012 21:30:21 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Mar 2012 17:30:20 -0500
From: ssenthil <ssenthil@cisco.com>
To: Cameron Byrne <cb.list6@gmail.com>
Message-ID: <CB83E32C.249A3%ssenthil@cisco.com>
Thread-Topic: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
Thread-Index: Ac0Al1M6N84zXFbNVkaNF6G8K6ZaHQ==
In-Reply-To: <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Mar 2012 21:30:33.0132 (UTC) FILETIME=[5B0E06C0:01CD0097]
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 21:30:35 -0000

Pls see inline.


<snip>
>> 
> 
> You said in the draft that EDM's negative characteristics exceed the
> positive attributes of maximizing address use with EDM and port
> overloading.  Thus, everyone should use EIM.
> 
> I said in my email, it is not possible to run a large network on a /22
> with EIM, and a /22 is all that a new entrant may get from an RIR per
> policy today in APNIC and soon in RIPE.  I think ARIN has a similar
> plan, but i have not seen it.
> 
> Thus, i do not think it is beneficial for the IETF to say EDM and port
> overloading are harmful or that EIM is a better "return on
> investment",   when it may be the only way to provide IPv4 service for
> new entrants.   My stance is that your assertion is wrong, the ability
> to compete and offer commercial service using EDM is superior than not
> offering service at all.  Thus, EDM exceeds that value of EIM (not
> offering service).  Saying EDM is harmful is negative statement to
> network operators that use it today (many do) and explicitly hurts new
> entrants that must use EDM and port overloading to offer legacy IPv4
> service.

Good, but you don't indicate how many customers called in to say that their
apps do not work, or how many hours was spent or how many dollars were spent
by the customer service in answering those calls.

On the other hand, I can tell you that many of the customers that I interact
with has been banging us for getting the EIM and EIF in the last couple of
years. To keep the balance I have also heard people asking us to do port
overloading lately but that is far less than the other. I know a lot of our
enterprise customers have EDM deployments in their networks (no port
overloading though) for many years, with handful of ALGs. But the landscape
is different when I talk to the SP customers as they don't have the control
on what apps can be used and supported.

> 
> Saying EDM is harmful and publishing in the IETF does not achieve
> anything in the real world, the only thing it does is confuse people
> who read and think EDM is an obviously unjustified path (the IETF said
> so ...) and design protocols and applications that assume EDM is not
> there, when it fact it is.  And, my guess is that EDM use will
> increase given the constraints on IPv4 space.
> 
> Your time is better spent writing a draft on how applications can
> better work in an EDM network, since that is the direction the
> internet is going (more ipv4 constraints)

I don't really agree that the direction is going to be NATs with EDMs.
Maybe I should ask you how many operators that you know deploy and embrace
EDM successfully? My experience suggests the opposite.

> 
>> 
<snip> 
>> IETF has taken a position to discourage any techniques that would prolong
>> the life of IPv4 and EDM does exactly that and in the process breaks apps.
>> 
> 
> Great. The IETF made another short sighted declaration to justify the
> use of tools like STUN.  That promulgation by the IETF in RFC4786 was
> rejected by hardware/software implementors and network operators who
> made EDM gear and deployed it.  So, now you want the IETF to say EDM
> is bad again, now that there is even less evidence or motivation that
> the suggestion will be listened to?
> 

You are making an assumption that EDM is widely deployed, I don't see any
evidence of that. 

> I am all for highlighting the technical ins and outs so everyone
> understand the operations of various network functions, but "harmful"
> drafts are like lightening rods.   Especially when all the available
> evidence shows that, on the real internet, EDM is helpful to network
> operators... and they are the ones that buy and deploy CGNs.
> 

I am more interested in documenting the applications that break with EDMs
that will cause more ALGs to be developed and less apps to be developed.
EDM cannot work with the MAP and PCP, which assumes that port overloading is
not used. I will focus more on the specifics of what applications will break
and why.

Thanks for your comments.
Senthil

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


From teemu.savolainen@nokia.com  Mon Mar 12 14:40:19 2012
Return-Path: <teemu.savolainen@nokia.com>
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 EF04D11E8162 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.661
X-Spam-Level: 
X-Spam-Status: No, score=-4.661 tagged_above=-999 required=5 tests=[AWL=1.938,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp75kgmi1QJ1 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:40:19 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4676F11E815E for <behave@ietf.org>; Mon, 12 Mar 2012 14:40:19 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2CLeGds007825; Mon, 12 Mar 2012 23:40:16 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 23:40:15 +0200
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Mon, 12 Mar 2012 22:40:14 +0100
From: <teemu.savolainen@nokia.com>
To: <marka@isc.org>, <dwing@cisco.com>
Thread-Topic: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
Thread-Index: AQHNAJi1wwpw6tTqXUiUzvrlh9/yNA==
Date: Mon, 12 Mar 2012 21:40:14 +0000
Message-ID: <916CE6CF87173740BC8A2CE443096962042F518A@008-AM1MPN1-053.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com> <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com> <000001cd0062$2852ea50$78f8bef0$@com> <20120312212858.0E1C61E68961@drugs.dv.isc.org>
In-Reply-To: <20120312212858.0E1C61E68961@drugs.dv.isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7InS4bkyy1NyMvQvnfS8p8RDUwo4BYy7JeAypGlqoE8L508UHXLwj4zVFZp7SVzD6u96Ii5sEHHUmgxS1Q2zZMgZlnU4+KA+gjD9TGuj2Nj4537A5r/YAIJTEpQ1EcmtulNEWTiNY7JPy71vnbBn1AXnSd/cdUMCgIhWYsg/aWvNH68GymGSwkwbKaahVT/V7V6neFcN31w00pL1nWULhiAj7dtsL/mjC5KaiwGgw+km7zVF1uyrK6J+GC3JnpAQruR9bYWzNC83Jt6z0TrEEBD0=
x-originating-ip: [10.162.86.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2012 21:40:15.0235 (UTC) FILETIME=[B603E530:01CD0098]
X-Nokia-AV: Clean
Cc: behave@ietf.org, stephan.lagerholm@secure64.com
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 21:40:20 -0000

> > The need for this pre-configured list of authorized domain names is
> > certainly not a good aspect of the DNSSEC scheme.  But it is necessary
> > to prevent the very attack you describe.
>=20
> So basically no security as the method also needs to work at Starbucks.

It does not necessarily. Starbucks may provide dual-stack (native, double t=
ranslated or tunneled) and be done with the problem.

	Teemu



From teemu.savolainen@nokia.com  Mon Mar 12 14:43:11 2012
Return-Path: <teemu.savolainen@nokia.com>
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 729CC11E8179 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.775
X-Spam-Level: 
X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[AWL=1.824,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO40MfUwunqs for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:43:10 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BD73A11E8171 for <behave@ietf.org>; Mon, 12 Mar 2012 14:43:10 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2CLh8FI010791; Mon, 12 Mar 2012 23:43:09 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 23:43:07 +0200
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Mon, 12 Mar 2012 22:43:07 +0100
From: <teemu.savolainen@nokia.com>
To: <marka@isc.org>, <dwing@cisco.com>
Thread-Topic: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
Thread-Index: AQHNAJi1wwpw6tTqXUiUzvrlh9/yNJZnMHOw
Date: Mon, 12 Mar 2012 21:43:06 +0000
Message-ID: <916CE6CF87173740BC8A2CE443096962042F51A2@008-AM1MPN1-053.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com> <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com> <000001cd0062$2852ea50$78f8bef0$@com> <20120312212858.0E1C61E68961@drugs.dv.isc.org> <916CE6CF87173740BC8A2CE443096962042F518A@008-AM1MPN1-053.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE443096962042F518A@008-AM1MPN1-053.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7InS4bkyy1NyMvQvnfS8p8RDUwo4BYy7JeAypGlqoE8L508UHXLwj4zVFZp7SVzD6u96Ii5sEHHUmgxS1Q2zZMgZlnU4+KA+gjD9TGuj2Nj4537A5r/YAIJTEpQ1EcmtulNEWTiNY7JPy71vnbBn1AXnSd/cdUMCgIhWYsg/aWvNH68GymGSwkwbKaahVT/V7V6neFcN31w00pL1nWULhiAj7dtsL/mjC5KaiwGgw+km7zVF1uyrK6J+GC3JnpAQruR9bYWzNC83Jt6z0TrEEBD0=
x-originating-ip: [10.162.86.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2012 21:43:07.0628 (UTC) FILETIME=[1CC4FAC0:01CD0099]
X-Nokia-AV: Clean
Cc: stephan.lagerholm@secure64.com, behave@ietf.org
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 21:43:11 -0000

..and it is always a possibility to have less connectivity in untrusted IPv=
6-only networks (no connectivity when facing IPv4 literals).

I.e. a device could do this procedure when it trusts the network (to some e=
xtent) and not to do elsewhere.

        Teemu

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Savolainen Teemu (Nokia-NRC/Tampere)
> Sent: 12. maaliskuuta 2012 23:40
> To: marka@isc.org; dwing@cisco.com
> Cc: behave@ietf.org; stephan.lagerholm@secure64.com
> Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
>
>
> > > The need for this pre-configured list of authorized domain names is
> > > certainly not a good aspect of the DNSSEC scheme.  But it is
> > > necessary to prevent the very attack you describe.
> >
> > So basically no security as the method also needs to work at Starbucks.
>
> It does not necessarily. Starbucks may provide dual-stack (native, double
> translated or tunneled) and be done with the problem.
>
>       Teemu
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From cb.list6@gmail.com  Mon Mar 12 14:50:11 2012
Return-Path: <cb.list6@gmail.com>
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 5F50421F89B6 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.457
X-Spam-Level: 
X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cezQJnJPlrVt for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 14:50:10 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4BA21F89BC for <behave@ietf.org>; Mon, 12 Mar 2012 14:50:05 -0700 (PDT)
Received: by dakl33 with SMTP id l33so6134824dak.31 for <behave@ietf.org>; Mon, 12 Mar 2012 14:50:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ROMQ3bx7oK2Bm2/C3cQukuqmAfHGgVW92j6oItKOx28=; b=NWacwwMiQHXUV0GW2OhMrVHDT4Koe94NOnOdYylzVac5lAKKwtSa5K59F2qXwssORI ezD4GdzbHqgMBAW3J+uZdPcYUtA/EoRXRfy/uyxGNYKkg52v7LHQ9yNJDzAmgusnT9NW k6NOSu+jutJJK99Q1+4UhkNROgXXVPD03i6KKF6lykGpzUmBFcpijWsyQIHiPI7tzdHW cJ0RdgOe5VmHOf649ZuuZkNVBTBRFSYVVzeG24JtFxaz82anbcb2e3w0YWtsh+0aB0IY DRHo1mPeE05uOCopj53paL3VtQU3rh9XxaEP84NHnhhWWy0T6MQ3LNaOMVotwWNU+4YM NnaQ==
MIME-Version: 1.0
Received: by 10.68.129.100 with SMTP id nv4mr3080844pbb.109.1331589005304; Mon, 12 Mar 2012 14:50:05 -0700 (PDT)
Received: by 10.142.163.16 with HTTP; Mon, 12 Mar 2012 14:50:05 -0700 (PDT)
In-Reply-To: <CB83E32C.249A3%ssenthil@cisco.com>
References: <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com> <CB83E32C.249A3%ssenthil@cisco.com>
Date: Mon, 12 Mar 2012 14:50:05 -0700
Message-ID: <CAD6AjGRrEicgw+vmMo_nkSWY5mxenAgCjS+D5tVkSidiHR5mmQ@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: ssenthil <ssenthil@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 21:50:11 -0000

On Mon, Mar 12, 2012 at 3:30 PM, ssenthil <ssenthil@cisco.com> wrote:
> Pls see inline.
>
>
> <snip>
>>>
>>
>> You said in the draft that EDM's negative characteristics exceed the
>> positive attributes of maximizing address use with EDM and port
>> overloading. =A0Thus, everyone should use EIM.
>>
>> I said in my email, it is not possible to run a large network on a /22
>> with EIM, and a /22 is all that a new entrant may get from an RIR per
>> policy today in APNIC and soon in RIPE. =A0I think ARIN has a similar
>> plan, but i have not seen it.
>>
>> Thus, i do not think it is beneficial for the IETF to say EDM and port
>> overloading are harmful or that EIM is a better "return on
>> investment", =A0 when it may be the only way to provide IPv4 service for
>> new entrants. =A0 My stance is that your assertion is wrong, the ability
>> to compete and offer commercial service using EDM is superior than not
>> offering service at all. =A0Thus, EDM exceeds that value of EIM (not
>> offering service). =A0Saying EDM is harmful is negative statement to
>> network operators that use it today (many do) and explicitly hurts new
>> entrants that must use EDM and port overloading to offer legacy IPv4
>> service.
>
> Good, but you don't indicate how many customers called in to say that the=
ir
> apps do not work, or how many hours was spent or how many dollars were sp=
ent
> by the customer service in answering those calls.
>
> On the other hand, I can tell you that many of the customers that I inter=
act
> with has been banging us for getting the EIM and EIF in the last couple o=
f
> years. To keep the balance I have also heard people asking us to do port
> overloading lately but that is far less than the other. I know a lot of o=
ur
> enterprise customers have EDM deployments in their networks (no port
> overloading though) for many years, with handful of ALGs. But the landsca=
pe
> is different when I talk to the SP customers as they don't have the contr=
ol
> on what apps can be used and supported.
>

So what you are saying is that there is no consensus, and that
different networks want / need / have different things.

Thus, you have no basis for a "harmful" draft.

>>
>> Saying EDM is harmful and publishing in the IETF does not achieve
>> anything in the real world, the only thing it does is confuse people
>> who read and think EDM is an obviously unjustified path (the IETF said
>> so ...) and design protocols and applications that assume EDM is not
>> there, when it fact it is. =A0And, my guess is that EDM use will
>> increase given the constraints on IPv4 space.
>>
>> Your time is better spent writing a draft on how applications can
>> better work in an EDM network, since that is the direction the
>> internet is going (more ipv4 constraints)
>
> I don't really agree that the direction is going to be NATs with EDMs.
> Maybe I should ask you how many operators that you know deploy and embrac=
e
> EDM successfully? My experience suggests the opposite.
>

My guess is that most major mobile providers are this way.  Since
those deployed CGN platforms are usually based on firewalls, i expect
EDM behavior unless shown otherwise.

>>
>>>
> <snip>
>>> IETF has taken a position to discourage any techniques that would prolo=
ng
>>> the life of IPv4 and EDM does exactly that and in the process breaks ap=
ps.
>>>
>>
>> Great. The IETF made another short sighted declaration to justify the
>> use of tools like STUN. =A0That promulgation by the IETF in RFC4786 was
>> rejected by hardware/software implementors and network operators who
>> made EDM gear and deployed it. =A0So, now you want the IETF to say EDM
>> is bad again, now that there is even less evidence or motivation that
>> the suggestion will be listened to?
>>
>
> You are making an assumption that EDM is widely deployed, I don't see any
> evidence of that.
>

I believe EDM is more widely deployed than EIM.  If you have data to
show otherwise, please show it.

>> I am all for highlighting the technical ins and outs so everyone
>> understand the operations of various network functions, but "harmful"
>> drafts are like lightening rods. =A0 Especially when all the available
>> evidence shows that, on the real internet, EDM is helpful to network
>> operators... and they are the ones that buy and deploy CGNs.
>>
>
> I am more interested in documenting the applications that break with EDMs
> that will cause more ALGs to be developed and less apps to be developed.

Great. Do that.  So far, you have not documented any applications that
break with EDM, AFAIK.

> EDM cannot work with the MAP and PCP, which assumes that port overloading=
 is
> not used. I will focus more on the specifics of what applications will br=
eak
> and why.
>

MAP and PCP also do not exist on the real internet.  In fact, they are
just drafts and not published standards, AFAIK.

CB

> Thanks for your comments.
> Senthil
>
>> CB
>>
>>> Senthil
>>>
>>>> CB
>>>> _______________________________________________
>>>> Behave mailing list
>>>> Behave@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>

From dwing@cisco.com  Mon Mar 12 15:09:06 2012
Return-Path: <dwing@cisco.com>
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 153A421F8A8A for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 15:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.969
X-Spam-Level: 
X-Spam-Status: No, score=-108.969 tagged_above=-999 required=5 tests=[AWL=1.630, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSORzs8jdV-o for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 15:09:05 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9691821F8A8E for <behave@ietf.org>; Mon, 12 Mar 2012 15:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3413; q=dns/txt; s=iport; t=1331590141; x=1332799741; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=lPRwrAUSJM5SVDnJqgNV76HojkXT9Lmf+XeyFsKkOgU=; b=VXlPmNon3zTigW/W7CLNeKl7G3IAQUvFb1sFVVJByqP1tRukhEd2JQfF 5Jz5XZ54NmogCMKYnx0SLJHTd57dhx5OwJlUjuyk9y1EGQH0Xd5wRkVGb N+Ve2RpPIAkyM6qPDJvvkCxy5U36N3p6DBQweurNkQG/Te7H2yKe6eBSK Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAD1zXk+rRDoH/2dsb2JhbABDpWyPaYEHggkBAQEECAoBFxA/DAEDAgkPAgQBASgHGSMKCQgBAQQTCxeFb4F4nREBnwORAQSIVIUPmAyDA4E2BhE
X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="33221551"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 12 Mar 2012 22:08:59 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CM8xiS020306; Mon, 12 Mar 2012 22:08:59 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Mark Andrews'" <marka@isc.org>
References: <916CE6CF87173740BC8A2CE443096962042F489E@008-AM1MPN1-053.mgdnok.nokia.com> <DD056A31A84CFC4AB501BD56D1E14BBBCA9F81@exchange.secure64.com> <000001cd0062$2852ea50$78f8bef0$@com> <20120312212858.0E1C61E68961@drugs.dv.isc.org>
In-Reply-To: <20120312212858.0E1C61E68961@drugs.dv.isc.org>
Date: Mon, 12 Mar 2012 15:08:59 -0700
Message-ID: <054b01cd009c$b9d6e960$2d84bc20$@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: Ac0AlzMKNtzlV1hmSluj6wRKVBkZZQABKR2g
Content-Language: en-us
Cc: behave@ietf.org, 'Stephan Lagerholm' <stephan.lagerholm@secure64.com>
Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-heuristic-06.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 22:09:06 -0000

> -----Original Message-----
> From: Mark Andrews [mailto:marka@isc.org]
> Sent: Monday, March 12, 2012 2:29 PM
> To: Dan Wing
> Cc: 'Stephan Lagerholm'; teemu.savolainen@nokia.com; behave@ietf.org
> Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-discovery-
> heuristic-06.txt
> 
> 
> In message <000001cd0062$2852ea50$78f8bef0$@com>, "Dan Wing" writes:
> > > -----Original Message-----
> > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> > > Behalf Of Stephan Lagerholm
> > > Sent: Monday, March 12, 2012 7:16 AM
> > > To: teemu.savolainen@nokia.com; behave@ietf.org
> > > Subject: Re: [BEHAVE] New revision:draft-ietf-behave-nat64-
> discovery-
> > > heuristic-06.txt
> > >
> > > Hi Teemu and the rest of the authors,
> > >
> > > I must be missing something but I can't see how the algorithm in
> > > section
> > > 3.1.1 is going to be secure. DNSSEC is not going to help here.
> > >
> > > Consider the following:
> > > An attacker with access to inject packets in the path between the
> node
> > > and the DNS64. The attacker is have the IPv6 network 6666::/48
> > > allocated
> > > to him, is running an evil NAT64 box at 6666::1 where he can listen
> to
> > > traffic and has registered the domain name example.com.
> > > 1.	Node sends a query for ipv4only.arpa. Attacker injects
> > > 6666::1.2.3.4 as the response
> > > 2.	Node sends PTR query for 6666::0. This reverse mapping is
> > > delegated to the attacker who is the rightful owner of the IPv6
> network
> > > 6666::/48. Attacker responds with evilnat64.example.com
> > > 3.	Node sends an AAAA query for evilnat64.example.com. This
> address
> > > is owned by the attacker, he responds with 6666::1 + Signatures for
> > > DNSSEC.
> > > 4.	Node performs DNSSEC validation.
> > > 5.	Node starts sending all traffic to the evil NAT64 box!!!
> >
> > The step missing is that the host needs a list of authorized domain
> > names.  So, for example, a Comcast subscriber would have comcast.net
> > on their list of authorized domain names.  If they take that computer
> > and visit a Starbucks coffee shop, they would be confronted with a
> > domain name other than comcast.net (e.g., "example.com" from your
> > above attack scenario) -- somewhat akin to what happens, today, with
> > choosing which of the dozens of SSIDs are "valid" when visiting a
> > Starbucks.
> >
> > The need for this pre-configured list of authorized domain names
> > is certainly not a good aspect of the DNSSEC scheme.  But it is
> > necessary to prevent the very attack you describe.
> 
> So basically no security as the method also needs to work at Starbucks.

When visiting Starbucks the user would have to include whatever 
FQDN Starbucks is legitimately using.  How the user determines that
legitimate FQDN (or legitimate SSID) is a problem generally unsolved by 
the industry, unless you have some magic up your sleeve?  Afterall,
if an attacker is in the van outside Starbucks with the SSID "Starbucks 
Coffee" (while the legitimate SSID is "Starbucks", unless it is "AT&T" (who
provides their WiFi in the US), unless it is "tmobile" (who used to
provide their WiFi in the US).  But the attacker would need to cause
the user to add the attacker's domain name to their list of my 
authorized NAT64's.

So, the problem reduces to a currently-unsolved problem.

-d



From ssenthil@cisco.com  Mon Mar 12 15:28:50 2012
Return-Path: <ssenthil@cisco.com>
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 6373E21E8055 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 15:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.442
X-Spam-Level: 
X-Spam-Status: No, score=-9.442 tagged_above=-999 required=5 tests=[AWL=1.157,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NwYxdTnWRwn for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 15:28:49 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E679D21F8A21 for <behave@ietf.org>; Mon, 12 Mar 2012 15:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=5945; q=dns/txt; s=iport; t=1331591321; x=1332800921; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=f7nNMZVUpiUcHfuXZ7q2Yyd0Ni/bX4rc+jRPRHxdkNQ=; b=arRIiwN9QYnMroOcpEbX7Q3lDnhTE0zTewewWWqeMeIPyE0b9zxPAlKq 0X6nF716+a74FHoioCGjwKLa4drkDc7X4uSb/+39JGbOIvhq+KNxVhx8k 82RaiTv7aaZQwTkONq6UMqjAwfSNNTNGGDnMOj97+nXPMGfee1Kmg9eKH U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEl4Xk+tJV2a/2dsb2JhbABDtVWBB4IJAQEBAwEBAQELBAEpASgFBAsFDQEICQUKTwYwAQEEDgUZCYdjBAELnQ0Bnn8EiUSHPQSIITOFJIdUiyuEeIMBgT4
X-IronPort-AV: E=Sophos;i="4.73,574,1325462400"; d="scan'208";a="65826889"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2012 22:28:40 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CMSe3C027178;  Mon, 12 Mar 2012 22:28:40 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 15:28:40 -0700
Received: from 10.117.198.135 ([10.117.198.135]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 12 Mar 2012 22:28:39 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 12 Mar 2012 18:28:38 -0500
From: ssenthil <ssenthil@cisco.com>
To: Cameron Byrne <cb.list6@gmail.com>
Message-ID: <CB83F0D6.249B9%ssenthil@cisco.com>
Thread-Topic: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
Thread-Index: Ac0An3gynxeEa7O9yEeo9AdvJ+0xbg==
In-Reply-To: <CAD6AjGRrEicgw+vmMo_nkSWY5mxenAgCjS+D5tVkSidiHR5mmQ@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 12 Mar 2012 22:28:40.0678 (UTC) FILETIME=[79CB5060:01CD009F]
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 22:28:50 -0000

On 3/12/12 4:50 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

> On Mon, Mar 12, 2012 at 3:30 PM, ssenthil <ssenthil@cisco.com> wrote:
>> Pls see inline.
>>=20
>>=20
>> <snip>
>>>>=20
>>>=20
>>> You said in the draft that EDM's negative characteristics exceed the
>>> positive attributes of maximizing address use with EDM and port
>>> overloading. =A0Thus, everyone should use EIM.
>>>=20
>>> I said in my email, it is not possible to run a large network on a /22
>>> with EIM, and a /22 is all that a new entrant may get from an RIR per
>>> policy today in APNIC and soon in RIPE. =A0I think ARIN has a similar
>>> plan, but i have not seen it.
>>>=20
>>> Thus, i do not think it is beneficial for the IETF to say EDM and port
>>> overloading are harmful or that EIM is a better "return on
>>> investment", =A0 when it may be the only way to provide IPv4 service for
>>> new entrants. =A0 My stance is that your assertion is wrong, the ability
>>> to compete and offer commercial service using EDM is superior than not
>>> offering service at all. =A0Thus, EDM exceeds that value of EIM (not
>>> offering service). =A0Saying EDM is harmful is negative statement to
>>> network operators that use it today (many do) and explicitly hurts new
>>> entrants that must use EDM and port overloading to offer legacy IPv4
>>> service.
>>=20
>> Good, but you don't indicate how many customers called in to say that th=
eir
>> apps do not work, or how many hours was spent or how many dollars were s=
pent
>> by the customer service in answering those calls.
>>=20
>> On the other hand, I can tell you that many of the customers that I inte=
ract
>> with has been banging us for getting the EIM and EIF in the last couple =
of
>> years. To keep the balance I have also heard people asking us to do port
>> overloading lately but that is far less than the other. I know a lot of =
our
>> enterprise customers have EDM deployments in their networks (no port
>> overloading though) for many years, with handful of ALGs. But the landsc=
ape
>> is different when I talk to the SP customers as they don't have the cont=
rol
>> on what apps can be used and supported.
>>=20
>=20
> So what you are saying is that there is no consensus, and that
> different networks want / need / have different things.
>=20
> Thus, you have no basis for a "harmful" draft.
>=20
Consensus for writing a draft from all the network operators? I don't know
where you got that idea that for one to "write" a draft there should be
consensus. Regarding your statement on the basis for that draft, that is
your subjective opinion and you are entitled to yours just like I am
entitled to mine.

>>>=20
>>> Saying EDM is harmful and publishing in the IETF does not achieve
>>> anything in the real world, the only thing it does is confuse people
>>> who read and think EDM is an obviously unjustified path (the IETF said
>>> so ...) and design protocols and applications that assume EDM is not
>>> there, when it fact it is. =A0And, my guess is that EDM use will
>>> increase given the constraints on IPv4 space.
>>>=20
>>> Your time is better spent writing a draft on how applications can
>>> better work in an EDM network, since that is the direction the
>>> internet is going (more ipv4 constraints)
>>=20
>> I don't really agree that the direction is going to be NATs with EDMs.
>> Maybe I should ask you how many operators that you know deploy and embra=
ce
>> EDM successfully? My experience suggests the opposite.
>>=20
>=20
> My guess is that most major mobile providers are this way.  Since
> those deployed CGN platforms are usually based on firewalls, i expect
> EDM behavior unless shown otherwise.
>=20
Your guess?=20

>>>=20
>>>>=20
>> <snip>
>>>> IETF has taken a position to discourage any techniques that would prol=
ong
>>>> the life of IPv4 and EDM does exactly that and in the process breaks a=
pps.
>>>>=20
>>>=20
>>> Great. The IETF made another short sighted declaration to justify the
>>> use of tools like STUN. =A0That promulgation by the IETF in RFC4786 was
>>> rejected by hardware/software implementors and network operators who
>>> made EDM gear and deployed it. =A0So, now you want the IETF to say EDM
>>> is bad again, now that there is even less evidence or motivation that
>>> the suggestion will be listened to?
>>>=20
>>=20
>> You are making an assumption that EDM is widely deployed, I don't see an=
y
>> evidence of that.
>>=20
>=20
> I believe EDM is more widely deployed than EIM.  If you have data to
> show otherwise, please show it.

I believe otherwise.
>=20
>>> I am all for highlighting the technical ins and outs so everyone
>>> understand the operations of various network functions, but "harmful"
>>> drafts are like lightening rods. =A0 Especially when all the available
>>> evidence shows that, on the real internet, EDM is helpful to network
>>> operators... and they are the ones that buy and deploy CGNs.
>>>=20
>>=20
>> I am more interested in documenting the applications that break with EDM=
s
>> that will cause more ALGs to be developed and less apps to be developed.
>=20
> Great. Do that.  So far, you have not documented any applications that
> break with EDM, AFAIK.
>=20
I will.

>> EDM cannot work with the MAP and PCP, which assumes that port overloadin=
g is
>> not used. I will focus more on the specifics of what applications will b=
reak
>> and why.
>>=20
>=20
> MAP and PCP also do not exist on the real internet.  In fact, they are
> just drafts and not published standards, AFAIK.
>=20
> CB
>=20
>> Thanks for your comments.
>> Senthil
>>=20
>>> CB
>>>=20
>>>> Senthil
>>>>=20
>>>>> CB
>>>>> _______________________________________________
>>>>> Behave mailing list
>>>>> Behave@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>=20
>>=20


From ovautrin@juniper.net  Mon Mar 12 15:53:00 2012
Return-Path: <ovautrin@juniper.net>
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 74FA921E8170 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 15:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5c60fjhRvFN for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 15:53:00 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id B266021E817E for <behave@ietf.org>; Mon, 12 Mar 2012 15:52:59 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT15+Sh6Vs0sxkqeEmR4tgPV+Z81qinvD@postini.com; Mon, 12 Mar 2012 15:52:59 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 12 Mar 2012 15:52:49 -0700
From: Olivier Vautrin <ovautrin@juniper.net>
To: ssenthil <ssenthil@cisco.com>, Cameron Byrne <cb.list6@gmail.com>
Date: Mon, 12 Mar 2012 15:52:48 -0700
Thread-Topic: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
Thread-Index: Ac0Aotj2X0tQVLCPSWGcB6iasRyQGQ==
Message-ID: <CB83C8BD.376D1%ovautrin@juniper.net>
In-Reply-To: <CB83E32C.249A3%ssenthil@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 22:53:00 -0000

You could use EIM only for the ports used for PCP. That way normal traffic
(not using PCP), would use EDM/Overloading.

The IETF is already advising the use of EIM with RFC4787, which is good.
But EDM is not "harmful" in a generic way. It is harmful if badly used,
which is the case of most technologies. There are cases where
EDM/Overloading is needed.

I do think that a draft listing all the issues with EDM would be useful
though.

/Olivier

On 3/12/12 3:30 PM, "ssenthil" <ssenthil@cisco.com> wrote:

>>=20
>
>I am more interested in documenting the applications that break with EDMs
>that will cause more ALGs to be developed and less apps to be developed.
>EDM cannot work with the MAP and PCP, which assumes that port overloading
>is
>not used. I will focus more on the specifics of what applications will
>break
>and why.
>
>Thanks for your comments.
>Senthil
>
>> CB
>>=20
>>> Senthil
>>>=20
>>>> CB
>>>> _______________________________________________
>>>> Behave mailing list
>>>> Behave@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>=20
>
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave


From cb.list6@gmail.com  Mon Mar 12 16:01:21 2012
Return-Path: <cb.list6@gmail.com>
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 C474A21F8A96 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 16:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level: 
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTnFSPiQ3OvN for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 16:01:21 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3EAF21F8A8D for <behave@ietf.org>; Mon, 12 Mar 2012 16:01:20 -0700 (PDT)
Received: by dakl33 with SMTP id l33so6204535dak.31 for <behave@ietf.org>; Mon, 12 Mar 2012 16:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d/iKgdWNlVQTga9h1xSTEx4bjdTwdAdjFIaYDIKcKSQ=; b=cXzDbtDQBFpNmlFCyKgfOCieBKtHxKTMZgtffbBrZba6HCY1OlCiqB/4Sy2mPEBjEh jTzcZ2IcCM+OGfzHHJXmnYIyai8LqCALMgP5f1C3YK7JyoNWnYvfJ0N59wfuQPLJ2DV7 PvxWCc/AFy5KyhpbFSHV2uAU4LSGlvwABy8KP0QGwOB6v523BRCSoeFTKwxW9KNRuVPx EWaA+9YSjwzNzgN0nwK04IBnd+XUMnIhCDI9L75LyC/+vwXLaR/S7q0JY/uoTydZQ3OU o9kdeZ4gMGryQOegLXT0v/6v00bIfgRsMF46FXneRA2nn/MtqFATEvs+AbxYIjDx5kOe dz6g==
MIME-Version: 1.0
Received: by 10.68.129.195 with SMTP id ny3mr18919813pbb.88.1331593280703; Mon, 12 Mar 2012 16:01:20 -0700 (PDT)
Received: by 10.142.163.16 with HTTP; Mon, 12 Mar 2012 16:01:20 -0700 (PDT)
In-Reply-To: <CB83F0D6.249B9%ssenthil@cisco.com>
References: <CAD6AjGRrEicgw+vmMo_nkSWY5mxenAgCjS+D5tVkSidiHR5mmQ@mail.gmail.com> <CB83F0D6.249B9%ssenthil@cisco.com>
Date: Mon, 12 Mar 2012 16:01:20 -0700
Message-ID: <CAD6AjGSzu5UoCBYfAarSs_AZs=2ofwOM4rBNN+fYaO3DOyTvMw@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: ssenthil <ssenthil@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 23:01:22 -0000

<snip>
>> My guess is that most major mobile providers are this way. =A0Since
>> those deployed CGN platforms are usually based on firewalls, i expect
>> EDM behavior unless shown otherwise.
>>
> Your guess?
>

I will be humble and say yes, a guess.

A little bit of Googling resulted in this public info , not a
definitive data source, but it is one data point

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010076-en.pdf

Page 18

"Although EIM is a supported feature and requested by many customers,
it is not widely used at this point because
applications have grown to be able to traverse NAT and receive inbound
connections over the same outbound connection.
Also, applications that need ALGs are still prevalent.
If EIM is needed, it should be on a per application basis. In other
words, only enable EIM for the applications that need it"


CB

From ovautrin@juniper.net  Mon Mar 12 16:05:12 2012
Return-Path: <ovautrin@juniper.net>
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 4E39621E81B8 for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 16:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Level: 
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg8LSJvhnXhB for <behave@ietfa.amsl.com>; Mon, 12 Mar 2012 16:05:11 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BAFDC21E81B7 for <behave@ietf.org>; Mon, 12 Mar 2012 16:05:10 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT16BJT/J/AhweHj0qS/dL1NPBequdhZa@postini.com; Mon, 12 Mar 2012 16:05:10 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 12 Mar 2012 16:04:46 -0700
From: Olivier Vautrin <ovautrin@juniper.net>
To: ssenthil <ssenthil@cisco.com>, Cameron Byrne <cb.list6@gmail.com>
Date: Mon, 12 Mar 2012 16:04:45 -0700
Thread-Topic: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
Thread-Index: Ac0ApIRQONl3d5wlQIG4c/+edw3U7Q==
Message-ID: <CB83CD97.37703%ovautrin@juniper.net>
In-Reply-To: <CB83F0D6.249B9%ssenthil@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 23:05:12 -0000

I agree with Cameron. It is difficult to have the full view of what is
deployed but my opinion is that EDM is more widely deployed than EIM today
in mobile environment. It will probably change though with RFC4787 but it
will take time.

/Olivier

On 3/12/12 4:28 PM, "ssenthil" <ssenthil@cisco.com> wrote:

>
>On 3/12/12 4:50 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:
>
>>
>>>=20
>>=20
>> My guess is that most major mobile providers are this way.  Since
>> those deployed CGN platforms are usually based on firewalls, i expect
>> EDM behavior unless shown otherwise.
>>=20
>Your guess?=20
>
>>>>=20
>>>>>=20
>>> <snip>
>>>>> IETF has taken a position to discourage any techniques that would
>>>>>prolong
>>>>> the life of IPv4 and EDM does exactly that and in the process breaks
>>>>>apps.
>>>>>=20
>>>>=20
>>>> Great. The IETF made another short sighted declaration to justify the
>>>> use of tools like STUN.  That promulgation by the IETF in RFC4786 was
>>>> rejected by hardware/software implementors and network operators who
>>>> made EDM gear and deployed it.  So, now you want the IETF to say EDM
>>>> is bad again, now that there is even less evidence or motivation that
>>>> the suggestion will be listened to?
>>>>=20
>>>=20
>>> You are making an assumption that EDM is widely deployed, I don't see
>>>any
>>> evidence of that.
>>>=20
>>=20
>> I believe EDM is more widely deployed than EIM.  If you have data to
>> show otherwise, please show it.
>
>I believe otherwise.
>>=20
>>>>


From internet-drafts@ietf.org  Tue Mar 13 02:37:46 2012
Return-Path: <internet-drafts@ietf.org>
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 F19EF21F879F; Tue, 13 Mar 2012 02:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.585
X-Spam-Level: 
X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv0XdcM84+VT; Tue, 13 Mar 2012 02:37:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773A921F879A; Tue, 13 Mar 2012 02:37:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120313093745.17155.46302.idtracker@ietfa.amsl.com>
Date: Tue, 13 Mar 2012 02:37:45 -0700
Cc: behave@ietf.org
Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-07.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2012 09:37:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Behavior Engineering for Hindrance Av=
oidance Working Group of the IETF.

	Title           : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
	Author(s)       : Teemu Savolainen
                          Jouni Korhonen
                          Dan Wing
	Filename        : draft-ietf-behave-nat64-discovery-heuristic-07.txt
	Pages           : 14
	Date            : 2012-03-12

   This document describes a method for detecting presence of DNS64 and
   for learning IPv6 prefix used for protocol translation on an access
   network.  The method depends on existence of a well-known IPv4-only
   domain name "ipv4only.arpa".  The information learned enables nodes
   to perform local IPv6 address synthesis and to potentially avoid
   traversal through NAT64 on dual-stack accesses and multi-interface
   deployments.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri=
stic-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris=
tic-07.txt


From teemu.savolainen@nokia.com  Tue Mar 13 02:43:41 2012
Return-Path: <teemu.savolainen@nokia.com>
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 E29A321F8659 for <behave@ietfa.amsl.com>; Tue, 13 Mar 2012 02:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG5vE5FmKPDz for <behave@ietfa.amsl.com>; Tue, 13 Mar 2012 02:43:41 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 35D7821F8658 for <behave@ietf.org>; Tue, 13 Mar 2012 02:43:41 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2D9hG1V006453 for <behave@ietf.org>; Tue, 13 Mar 2012 11:43:38 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 13 Mar 2012 11:43:27 +0200
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Tue, 13 Mar 2012 10:43:25 +0100
From: <teemu.savolainen@nokia.com>
To: <behave@ietf.org>
Thread-Topic: Quick update to draft-ietf-behave-nat64-discovery-heuristic-07.txt
Thread-Index: Ac0A/YDbH5CJmyboSpe45t03f4FH4Q==
Date: Tue, 13 Mar 2012 09:43:25 +0000
Message-ID: <916CE6CF87173740BC8A2CE443096962042F5695@008-AM1MPN1-053.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: 4lI8lld/Cs6gJozBIdd2wGlvGErgPrcAvvNBwnvAwK3Xk/Xv442VuaXM5POEjM17eLDG5Au/PuRn4U43xuMA8rnFP0JJdtYR+Z88k5S1xgyMrBzYXFePzyLb7RA1Ok2Ih11CqzW5gOKrg8GYxECJAYorOtTGXbBMmWFhiHJScugiOeZtm2Qc1hJEWsKki8jBrKVFHxw4saYy8rQUkdMo+KCvvebaFFqdtoeQk7kTe/O41Kvt1vY4t7lLTyNLWO4+De+isNrEdb4pcM4ydtkNRkP8zEbT8K/4OQfmAGILY64=
x-originating-ip: [88.115.224.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Mar 2012 09:43:27.0627 (UTC) FILETIME=[BDE575B0:01CD00FD]
X-Nokia-AV: Clean
Subject: [BEHAVE] Quick update to draft-ietf-behave-nat64-discovery-heuristic-07.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2012 09:43:42 -0000

Hi,

Here's a quick update to add one step for node behavior in case of DNSSEC u=
se:
--
   3.  The node SHOULD compare the domain of the NAT64 FQDN with node's
       list of trusted domains.  The means for node to learn the trusted
       domains is implementation specific.  If the node has no list of
       trusted domains, the node MAY query user whether the domain can
       be trusted.  The node MAY remember the answer for future use.  If
       the node has no trust for the domain, the discovery procedure is
       not secure and remaining steps described below are not needed.
--

Also the exit strategy section is now stripped to bare minimum without any =
speculation about exit tools:
--
6.  Exit Strategy

   A day will come when this tool is no longer needed.  At that point
   best suited techniques for implementing exit strategy will be
   documented.

   A node SHOULD implement configuration knob for disabling the
   Pref64::/n discovery feature.
--

Best regards,

        Teemu

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of ext internet-drafts@ietf.org
> Sent: 13. maaliskuuta 2012 11:38
> To: i-d-announce@ietf.org
> Cc: behave@ietf.org
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic=
-
> 07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Behavior Engineering for Hindrance
> Avoidance Working Group of the IETF.
>
>       Title           : Discovery of IPv6 Prefix Used for IPv6 Address Sy=
nthesis
>       Author(s)       : Teemu Savolainen
>                           Jouni Korhonen
>                           Dan Wing
>       Filename        : draft-ietf-behave-nat64-discovery-heuristic-07.tx=
t
>       Pages           : 14
>       Date            : 2012-03-12
>
>    This document describes a method for detecting presence of DNS64 and
>    for learning IPv6 prefix used for protocol translation on an access
>    network.  The method depends on existence of a well-known IPv4-only
>    domain name "ipv4only.arpa".  The information learned enables nodes
>    to perform local IPv6 address synthesis and to potentially avoid
>    traversal through NAT64 on dual-stack accesses and multi-interface
>    deployments.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-
> heuristic-07.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heur=
istic-
> 07.txt
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

From mohamed.boucadair@orange.com  Fri Mar 16 07:28:02 2012
Return-Path: <mohamed.boucadair@orange.com>
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 E279321F8686 for <behave@ietfa.amsl.com>; Fri, 16 Mar 2012 07:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level: 
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTwcU1bJdOT5 for <behave@ietfa.amsl.com>; Fri, 16 Mar 2012 07:28:02 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9621F8649 for <behave@ietf.org>; Fri, 16 Mar 2012 07:28:02 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 255FD2DC6F7; Fri, 16 Mar 2012 15:28:01 +0100 (CET)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 068BF2380EB; Fri, 16 Mar 2012 15:28:01 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 16 Mar 2012 15:28:00 +0100
From: <mohamed.boucadair@orange.com>
To: Cameron Byrne <cb.list6@gmail.com>, ssenthil <ssenthil@cisco.com>
Date: Fri, 16 Mar 2012 15:27:59 +0100
Thread-Topic: Experimental data in moble networks (was RE: [BEHAVE] draft-sivakumar-behave-edm-harmful comments)
Thread-Index: Ac0AmjSq7KwsFgGtRpm8PGrzRzG3UgC46lyQ
Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557AB6@PUEXCB1B.nanterre.francetelecom.fr>
References: <CAD6AjGR4fVnMJEU5ThieXySdN9+8mxS7kMAV47aRWbT6+bbR9g@mail.gmail.com> <CB83E32C.249A3%ssenthil@cisco.com> <CAD6AjGRrEicgw+vmMo_nkSWY5mxenAgCjS+D5tVkSidiHR5mmQ@mail.gmail.com>
In-Reply-To: <CAD6AjGRrEicgw+vmMo_nkSWY5mxenAgCjS+D5tVkSidiHR5mmQ@mail.gmail.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.13.105415
Cc: "behave@ietf.org" <behave@ietf.org>, Zhiyun Qian <zhiyunq@umich.edu>
Subject: [BEHAVE] Experimental data in moble networks (was RE: draft-sivakumar-behave-edm-harmful comments)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2012 14:28:03 -0000

Dear Cameron, Senthil,

For the point discussed below, I recommend you to read this interesting pap=
er (in particular Table 3)=20

http://research.microsoft.com/en-us/people/mzh/netpiculet.pdf.


(I cc Zhiyung who can provide you more information if needed)

Cheers,
Med=20

>-----Message d'origine-----
>De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20
>De la part de Cameron Byrne
>Envoy=E9 : lundi 12 mars 2012 22:50
>=C0 : ssenthil
>Cc : behave@ietf.org
>Objet : Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
>
>On Mon, Mar 12, 2012 at 3:30 PM, ssenthil <ssenthil@cisco.com> wrote:
>> Pls see inline.
>>

>>
>> You are making an assumption that EDM is widely deployed, I=20
>don't see any
>> evidence of that.
>>
>
>I believe EDM is more widely deployed than EIM.  If you have data to
>show otherwise, please show it.
>
>=

From joelja@bogus.com  Sun Mar 18 08:58:05 2012
Return-Path: <joelja@bogus.com>
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 9C5EB21F8674 for <behave@ietfa.amsl.com>; Sun, 18 Mar 2012 08:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yomWxkI2plfl for <behave@ietfa.amsl.com>; Sun, 18 Mar 2012 08:58:05 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0837221F8598 for <behave@ietf.org>; Sun, 18 Mar 2012 08:58:04 -0700 (PDT)
Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2IFw2jQ011411 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 18 Mar 2012 15:58:03 GMT (envelope-from joelja@bogus.com)
Message-ID: <4F66060A.2020906@bogus.com>
Date: Sun, 18 Mar 2012 08:58:02 -0700
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: Cameron Byrne <cb.list6@gmail.com>
References: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com>
In-Reply-To: <CAD6AjGRXwVptiT4m2c7Seo6AaOBsO0y5fReeTxxOrXWFhwW9jg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 18 Mar 2012 15:58:03 +0000 (UTC)
Cc: behave@ietf.org
Subject: Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2012 15:58:05 -0000

I'm not sure what to think if this draft.

The way I read it some load balancer deployments that I currently have
are considered harmful. that may well be but they meet my needs so
there's a question of scope. not all edm devices sit between isp
customers and the internet.

On 3/10/12 05:50 , Cameron Byrne wrote:
...

> Trying to keep the math simple here, 64,000 available ports * 1024
> IPv4 addresses = 65.5 million sessions.  Just as one data point, i
> cannot run my network on this allocation, assuming i put 100% of the
> allocation to CGN use.

If I don't have enough IPs to meet the requirement for a non-edm mapping
while fulfilling my other addressing needs with available resources I'm
going to overload, no matter what the draft says. If we would like to
provide advice that should be soundly ignored when necessary I'm not
sure what the value of the advice is.


From stephan.lagerholm@secure64.com  Mon Mar 26 06:32:51 2012
Return-Path: <stephan.lagerholm@secure64.com>
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 778A321F85B1 for <behave@ietfa.amsl.com>; Mon, 26 Mar 2012 06:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.805
X-Spam-Level: 
X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-1.300,  BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5cNWXhQPH1C for <behave@ietfa.amsl.com>; Mon, 26 Mar 2012 06:32:50 -0700 (PDT)
Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7F621F8598 for <behave@ietf.org>; Mon, 26 Mar 2012 06:32:49 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id E69B7B84E2; Mon, 26 Mar 2012 07:32:48 -0600 (MDT)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn1OR88Z1pT8; Mon, 26 Mar 2012 07:32:46 -0600 (MDT)
Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id 619C7B84E1; Mon, 26 Mar 2012 07:32:46 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1332768766; bh=mzJT+KtDUwTKZHsOi/ass+wEwS7DN7TOvrUOZDq5WL8=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:From:To; b=tbPREOy3QxhOu4cMfmNYbSq99EZfozRNrjT/QjPm4qqu KYJeyLq2YkARI2ujha0EEs8LxvMoMmfSWFeYQiQVosSwNFoeqPFZ7fU8/GKLR65XUOA sj7ka8q5OoLycFOzNLkazTfibxLphnVh6TG7GPQmBnBoM0SUTavetYUVQRYE=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 07:32:45 -0600
Message-ID: <DD056A31A84CFC4AB501BD56D1E14BBBCAA42F@exchange.secure64.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DNSSEC checking tool
Thread-Index: Ac0LVO1729MwunaAR9ezlfF7K0SC5w==
From: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
To: "Benjamin Choy" <ben.choy@hkirc.hk>, <behave@ietf.org>, "Josh Wong" <josh.wong@hkirc.hk>
Subject: [BEHAVE] DNSSEC checking tool
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2012 13:32:51 -0000

Hi all,

The tool I talked about that could check the integrity of the DNS zone
is DNSSexy, (http://nlnetlabs.nl/mailman/listinfo/dnssexy)
However, I have not seen any development on the project lately.

I'm still checking with development about how separation between the key
generator and the key user can be acompished.

Thanks, Stephan



From bortzmeyer@nic.fr  Mon Mar 26 06:53:26 2012
Return-Path: <bortzmeyer@nic.fr>
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 DB24921E80A3 for <behave@ietfa.amsl.com>; Mon, 26 Mar 2012 06:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.049
X-Spam-Level: 
X-Spam-Status: No, score=-106.049 tagged_above=-999 required=5 tests=[AWL=-3.800, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZX1Q8Tj4iTd for <behave@ietfa.amsl.com>; Mon, 26 Mar 2012 06:53:26 -0700 (PDT)
Received: from mx5.nic.fr (mx5.nic.fr [192.134.4.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B021F85D9 for <behave@ietf.org>; Mon, 26 Mar 2012 06:53:26 -0700 (PDT)
Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id 55C81300626; Mon, 26 Mar 2012 15:53:03 +0200 (CEST)
Received: by mx5.nic.fr (Postfix, from userid 1137) id 4FFA7300657; Mon, 26 Mar 2012 15:53:03 +0200 (CEST)
Received: from relay1.nic.fr (relay1.nic.fr [IPv6:2001:67c:2218:9::4:162]) by mx5.nic.fr (Postfix) with ESMTP id 4A2B6300626; Mon, 26 Mar 2012 15:53:03 +0200 (CEST)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 3E6DC4C0006; Mon, 26 Mar 2012 15:53:03 +0200 (CEST)
Date: Mon, 26 Mar 2012 15:53:03 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Stephan Lagerholm <stephan.lagerholm@secure64.com>
Message-ID: <20120326135303.GA2931@nic.fr>
References: <DD056A31A84CFC4AB501BD56D1E14BBBCAA42F@exchange.secure64.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DD056A31A84CFC4AB501BD56D1E14BBBCAA42F@exchange.secure64.com>
X-Operating-System: Debian GNU/Linux wheezy/sid
X-Kernel: Linux 3.2.0-2-686-pae i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Bogosity: No, tests=bogofilter, spamicity=0.000007, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2012.3.26.133024
Cc: Benjamin Choy <ben.choy@hkirc.hk>, Josh Wong <josh.wong@hkirc.hk>, behave@ietf.org
Subject: Re: [BEHAVE] DNSSEC checking tool
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2012 13:53:27 -0000

On Mon, Mar 26, 2012 at 07:32:45AM -0600,
 Stephan Lagerholm <stephan.lagerholm@secure64.com> wrote 
 a message of 16 lines which said:

> The tool I talked about that could check the integrity of the DNS zone
> is DNSSexy, (http://nlnetlabs.nl/mailman/listinfo/dnssexy)
> However, I have not seen any development on the project lately.

There are several tools which implement the DNSsexy idea. The one I
use and highly recommend is validns
<https://github.com/tobez/validns>.