From nobody Mon Nov 3 06:41:45 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119061A0382 for ; Mon, 3 Nov 2014 06:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBq9iI9ZN0sH for ; Mon, 3 Nov 2014 06:41:33 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998BC1A037F for ; Mon, 3 Nov 2014 06:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2393; q=dns/txt; s=iport; t=1415025694; x=1416235294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LgQEsC9vzsJCMSgHJqMaWLlnKMVBX7DGPpK5vABp5TU=; b=VMose8XXKwsvb6Y+7hyraXhKa9cO5bYM0+tHZok4c05ZSFbIjXvUz0jI +w0in75M2a6Feup0XdO4I9Inpx4vk0YpAtBN7DKa//8B+gw/8doFV+3jK 8gxT5YEaZyKI7C3Iw48z4CHrGQR6AZy4MQyfwAOh0emfmvQqPEwbTowYQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFALCSV1StJV2R/2dsb2JhbABSCoMOVFMFBM4Ih0sCgSAWAQEBAQF9hAMBAQQ6PQIQAgEINhAyJQIEDgUJiDgIBcdTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AsCFwHhEsFkhqET4cYgTE9gxCRUoN4bIEGQoEDAQEB X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="92842748" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 03 Nov 2014 14:41:33 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sA3EfW8F006486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Nov 2014 14:41:32 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.58]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 08:41:32 -0600 From: "Senthil Sivakumar (ssenthil)" To: Spencer Dawkins Thread-Topic: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt Thread-Index: AQHPld6B6yZHcnkU10yuXw+ZkLKEl5uMsBEAgMMdeAA= Date: Mon, 3 Nov 2014 14:41:31 +0000 Message-ID: References: <20140702101019.29230.46453.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.150.38.181] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/ZyLyARKs44kA0T9NqGibGXp1UOA Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 14:41:37 -0000 Hi Spencer, I wanted to touch base with you to see if there are any updates on the progress of the logging drafts. Let us know if you are waiting on the authors on something. Thanks Senthil On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" wrote: >A new version of the draft is published incorporating all the comments >received. Please >Let me know if you see anything that we discussed and agreed upon is >missing. > >Thanks >Senthil > >On 7/2/14 6:10 AM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >>has been successfully submitted by Senthil Sivakumar and posted to the >>IETF repository. >> >>Name: draft-ietf-behave-ipfix-nat-logging >>Revision: 04 >>Title: IPFIX Information Elements for logging NAT Events >>Document date: 2014-07-02 >>Group: Individual Submission >>Pages: 24 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0 >>4 >>.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-ipfix-nat-logging-04 >> >>Abstract: >> Network operators expect NAT devices to log events like creation and >> deletion of translations and information about the resources it is >> managing. The logs are essential in many cases to identify an >> attacker or a host that was used to launch malicious attacks and/or >> for various other purposes of accounting. Since there is no standard >> way of logging this information, different NAT devices log the >> information using proprietary formats and hence it is difficult to >> expect a consistent behavior. The lack of a consistent way to log >> the data makes it difficult to write the collector applications that >> would receive this data and process it to present useful information. >> This document describes the formats for logging of NAT events. >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > From nobody Mon Nov 10 17:39:04 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9A1AD3A9 for ; Mon, 10 Nov 2014 17:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO4WgrawnAvQ for ; Mon, 10 Nov 2014 17:38:59 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BC71AD3A1 for ; Mon, 10 Nov 2014 17:38:58 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so6934013lbg.35 for ; Mon, 10 Nov 2014 17:38:57 -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; bh=joLcNc0TyGzA/2ZYlbhxIImEL/0QdJatKjWgTHoTsCM=; b=Rika9/Kuxdn3WFBoBotTOwqrgOeTC+HOFgyu3y1Y6Ks4j5cZ9s7v4BGyE/TqnPD9fR 02Rs5B41Vxvu1UX66yu2a7K0I0ZmknsJREx9+nC0ev3nvtn+x4X+9TC4yb1ivd0H9SB3 6D4rDAM5YWsTwTugZZQRUL77PjRAW8GCJL+NeJf4Ly65l+FGc5ulLo5sma/dteDjOLl+ NMpyQMGtMi/u7uDktEYR2ehilh6TERQqtQYj1qgLKOYaPdHN8MJt0sC7ZUSoUTYPEgMh LIXFUY2NiguqkXYZ3Z5+y9faqxLfJ/Zh5eHy8ZL71P0/dpUG1O8unrKkW31ToB2WL/f/ X7EA== MIME-Version: 1.0 X-Received: by 10.112.148.130 with SMTP id ts2mr33482866lbb.43.1415669937259; Mon, 10 Nov 2014 17:38:57 -0800 (PST) Received: by 10.152.131.35 with HTTP; Mon, 10 Nov 2014 17:38:57 -0800 (PST) In-Reply-To: References: <20140702101019.29230.46453.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 19:38:57 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Senthil Sivakumar (ssenthil)" Content-Type: multipart/alternative; boundary=047d7b3a81eabacc0605078b5787 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/oV7KXF_WqueRDQziWA9o_yxTenE Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 01:39:01 -0000 --047d7b3a81eabacc0605078b5787 Content-Type: text/plain; charset=UTF-8 Hi, Senthil, I'd love to talk to you about this draft (and to people about the MIB draft, and to people about the syslog draft) this week. Are you in Honolulu? Spencer On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) < ssenthil@cisco.com> wrote: > Hi Spencer, > I wanted to touch base with you to see if there are any updates on the > progress of the logging > drafts. Let us know if you are waiting on the authors on something. > > Thanks > Senthil > > On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" > > wrote: > > >A new version of the draft is published incorporating all the comments > >received. Please > >Let me know if you see anything that we discussed and agreed upon is > >missing. > > > >Thanks > >Senthil > > > >On 7/2/14 6:10 AM, "internet-drafts@ietf.org " < > internet-drafts@ietf.org > > >wrote: > > > >> > >>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt > >>has been successfully submitted by Senthil Sivakumar and posted to the > >>IETF repository. > >> > >>Name: draft-ietf-behave-ipfix-nat-logging > >>Revision: 04 > >>Title: IPFIX Information Elements for logging NAT Events > >>Document date: 2014-07-02 > >>Group: Individual Submission > >>Pages: 24 > >>URL: > >> > http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0 > >>4 > >>.txt > >>Status: > >>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ > >>Htmlized: > >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04 > >>Diff: > >>http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-ipfix-nat-logging-04 > >> > >>Abstract: > >> Network operators expect NAT devices to log events like creation and > >> deletion of translations and information about the resources it is > >> managing. The logs are essential in many cases to identify an > >> attacker or a host that was used to launch malicious attacks and/or > >> for various other purposes of accounting. Since there is no standard > >> way of logging this information, different NAT devices log the > >> information using proprietary formats and hence it is difficult to > >> expect a consistent behavior. The lack of a consistent way to log > >> the data makes it difficult to write the collector applications that > >> would receive this data and process it to present useful information. > >> This document describes the formats for logging of NAT events. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission > >>until the htmlized version and diff are available at tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > > --047d7b3a81eabacc0605078b5787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Senthil,

I'd love to talk to you about this draf= t (and to people about the MIB draft, and to people about the syslog draft)= this week. Are you in Honolulu?

Spencer

On= Monday, November 3, 2014, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com> wrote:
Hi Spencer,
I wanted to touch base with you to see if there are any updates on the
progress of the logging
drafts. Let us know if you are waiting on the authors on something.

Thanks
Senthil

On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
wrote:

>A new version of the draft is published incorporating all the comments<= br> >received. Please
>Let me know if you see anything that we discussed and agreed upon is >missing.
>
>Thanks
>Senthil
>
>On 7/2/14 6:10 AM, "internet-drafts@ietf.o= rg" <internet-drafts@ietf.org> >wrote:
>
>>
>>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >>has been successfully submitted by Senthil Sivakumar and posted to = the
>>IETF repository.
>>
>>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-behave-ipfix-nat-= logging
>>Revision:=C2=A0 =C2=A0 =C2=A004
>>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPFIX= Information Elements for logging NAT Events
>>Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-07-02
>>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indiv= idual Submission
>>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24 >>URL:
>>http://www.ietf.org/internet-drafts/dr= aft-ietf-behave-ipfix-nat-logging-0
>>4
>>.txt
>>Status:
>>https://datatracker.ietf.org/doc/draft-iet= f-behave-ipfix-nat-logging/
>>Htmlized:
>>http://tools.ietf.org/html/draft-ietf-behave-i= pfix-nat-logging-04
>>Diff:
>>http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-behave-ipfix-nat-logging-04
>>
>>Abstract:
>>=C2=A0 =C2=A0Network operators expect NAT devices to log events lik= e creation and
>>=C2=A0 =C2=A0deletion of translations and information about the res= ources it is
>>=C2=A0 =C2=A0managing.=C2=A0 The logs are essential in many cases t= o identify an
>>=C2=A0 =C2=A0attacker or a host that was used to launch malicious a= ttacks and/or
>>=C2=A0 =C2=A0for various other purposes of accounting.=C2=A0 Since = there is no standard
>>=C2=A0 =C2=A0way of logging this information, different NAT devices= log the
>>=C2=A0 =C2=A0information using proprietary formats and hence it is = difficult to
>>=C2=A0 =C2=A0expect a consistent behavior.=C2=A0 The lack of a cons= istent way to log
>>=C2=A0 =C2=A0the data makes it difficult to write the collector app= lications that
>>=C2=A0 =C2=A0would receive this data and process it to present usef= ul information.
>>=C2=A0 =C2=A0This document describes the formats for logging of NAT= events.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of >>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>

--047d7b3a81eabacc0605078b5787-- From nobody Mon Nov 10 17:52:41 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599D81AD3E1 for ; Mon, 10 Nov 2014 17:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip2rJiFPFS46 for ; Mon, 10 Nov 2014 17:52:34 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80181AD3D1 for ; Mon, 10 Nov 2014 17:52:33 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id rd18so10536771iec.27 for ; Mon, 10 Nov 2014 17:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uDWSzTGG2rXOhoqaubvSffvi4egFRC3e2N7fRTmbmRI=; b=ovv5YQAMvKOLss+fFCYbqfrSEVY4RzPwolXmapT8Dr3m571jSViaR4ceKmcMr1aho3 FlfzT+RnVFcIcVdeOIMuCPRFmtoizDlONgPkivhbDDKFY/bGMj1nJEr8pH5Buu2EEK0T 4FOe6i8vTJbw/p/soMJnfndq1HuGDcwQpTqm8N+K60gm1BgWzxi+i3dZetPfSmusaV+w byMGRIurXllZT9sFhfQjr411FiaMM6cJShmFy75/ARAyuO5QtZJSLAkV79v4VtzMbpbu eJQhy05YBHcQHEQcXndiGQCcxlkrrMRZ8Q9ZyYTBwxZGpFAi+X7zsda/fh47vF1IVlHK CfAg== X-Received: by 10.50.82.102 with SMTP id h6mr29326012igy.25.1415670753207; Mon, 10 Nov 2014 17:52:33 -0800 (PST) Received: from [192.168.0.102] ([64.56.224.121]) by mx.google.com with ESMTPSA id h199sm9131857ioh.0.2014.11.10.17.52.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 17:52:32 -0800 (PST) Message-ID: <54616BE2.30901@gmail.com> Date: Mon, 10 Nov 2014 20:52:34 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Spencer Dawkins at IETF , "Senthil Sivakumar (ssenthil)" References: <20140702101019.29230.46453.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/gGDBMUivIxz65Oy-BjpnXn7XPRo Cc: "behave@ietf.org" Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 01:52:37 -0000 Sorry I couldn't make it. Still highly at risk of complications. Toronto was an exceptional period, ended up in hospital for the next three months. I can phone in at whatever time you choose, if that works out. Tom On 10/11/2014 8:38 PM, Spencer Dawkins at IETF wrote: > Hi, Senthil, > > I'd love to talk to you about this draft (and to people about the MIB > draft, and to people about the syslog draft) this week. Are you in Honolulu? > > Spencer > > On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) > > wrote: > > Hi Spencer, > I wanted to touch base with you to see if there are any updates on the > progress of the logging > drafts. Let us know if you are waiting on the authors on something. > > Thanks > Senthil > >... From nobody Mon Nov 10 18:47:41 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959701AD4A1 for ; Mon, 10 Nov 2014 18:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjhKpJlw25Yr for ; Mon, 10 Nov 2014 18:47:36 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001B41AD49E for ; Mon, 10 Nov 2014 18:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10035; q=dns/txt; s=iport; t=1415674055; x=1416883655; h=from:to:cc:subject:date:message-id:mime-version; bh=t/5er4g5raU6z5cEJ45yT4iy/t9MUklWSLNWxWiuSVY=; b=iNyNU1101bVD0W1h7vlQTtxYeCYEWDaCpxvBjRw0FY2JybFo2RQK0QzJ g9cqn+rfNLm97vZxhfK5rQ/tSKh/hyNXyCtTcJ/esxr4sX1bUsXXokdbN HxXK7XoHDVmQ6oVE3wBUWdbFg9GSe+RJKOjB+TXI+XEuxak9nwmk0SPqm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FADR4YVStJA2D/2dsb2JhbABSCoJIRlRUBQTKEoFwh02BHhYBAQEBAX2EAgECBHcCEgEIEQMBAigoERQJCgQOBQmIIwMSCAXGHA2GUwEBAQEBAQQBAQEBAQEBARcDBgGOVYFVCEsNBBCEQgWSMYRThQ+CEoE0PYMSimyGcYN6bAGBBUKBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,357,1413244800"; d="scan'208,217"; a="95357689" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 11 Nov 2014 02:47:34 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sAB2lYAq011381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 02:47:35 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.48]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 20:47:34 -0600 From: "Senthil Sivakumar (ssenthil)" To: Spencer Dawkins at IETF Thread-Topic: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt Thread-Index: AQHP/VnYFHmkWST0Y0OIJ5fzEjQ1TQ== Date: Tue, 11 Nov 2014 02:47:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.82.226.192] Content-Type: multipart/alternative; boundary="_000_D086E2B911C463ssenthilciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/meMRJjCJQnTbcjY6duzy0_KQGhk Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:47:39 -0000 --_000_D086E2B911C463ssenthilciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I am not in Honolulu. Like Tom said I can be available for a phone call= . Thanks Senthil From: Spencer Dawkins at IETF > Date: Monday, November 10, 2014 8:38 PM To: Senthil Sivakumar > Cc: "behave@ietf.org" >, Tom Taylor > Subject: Re: FW: New Version Notification for draft-ietf-behave-ipfix-nat-l= ogging-04.txt Hi, Senthil, I'd love to talk to you about this draft (and to people about the MIB draft= , and to people about the syslog draft) this week. Are you in Honolulu? Spencer On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) > wrote: Hi Spencer, I wanted to touch base with you to see if there are any updates on the progress of the logging drafts. Let us know if you are waiting on the authors on something. Thanks Senthil On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" > wrote: >A new version of the draft is published incorporating all the comments >received. Please >Let me know if you see anything that we discussed and agreed upon is >missing. > >Thanks >Senthil > >On 7/2/14 6:10 AM, "internet-drafts@ietf.org" > >wrote: > >> >>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >>has been successfully submitted by Senthil Sivakumar and posted to the >>IETF repository. >> >>Name: draft-ietf-behave-ipfix-nat-logging >>Revision: 04 >>Title: IPFIX Information Elements for logging NAT Events >>Document date: 2014-07-02 >>Group: Individual Submission >>Pages: 24 >>URL: >>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0 >>4 >>.txt >>Status: >>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ >>Htmlized: >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04 >>Diff: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-ipfix-nat-logging-04 >> >>Abstract: >> Network operators expect NAT devices to log events like creation and >> deletion of translations and information about the resources it is >> managing. The logs are essential in many cases to identify an >> attacker or a host that was used to launch malicious attacks and/or >> for various other purposes of accounting. Since there is no standard >> way of logging this information, different NAT devices log the >> information using proprietary formats and hence it is difficult to >> expect a consistent behavior. The lack of a consistent way to log >> the data makes it difficult to write the collector applications that >> would receive this data and process it to present useful information. >> This document describes the formats for logging of NAT events. >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > --_000_D086E2B911C463ssenthilciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
No, I am not in Honolulu. Like Tom said I can be available for a phone= call.

Thanks
Senthil

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com">spencerdawkins.ietf@gmail.c= om>
Date: Monday, November 10, 2014 8:3= 8 PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <= behave@ietf.org>, Tom Taylor <tom.taylor.stds@gmail.com>
Subject: Re: FW: New Version Notifi= cation for draft-ietf-behave-ipfix-nat-logging-04.txt

Hi, Senthil,

I'd love to talk to you about this draft (and to people about the MIB = draft, and to people about the syslog draft) this week. Are you in Honolulu= ?

Spencer

On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com> wrote:
Hi Spencer,
I wanted to touch base with you to see if there are any updates on the
progress of the logging
drafts. Let us know if you are waiting on the authors on something.

Thanks
Senthil

On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" <ssenthil= @cisco.com>
wrote:

>A new version of the draft is published incorporating all the comments<= br> >received. Please
>Let me know if you see anything that we discussed and agreed upon is >missing.
>
>Thanks
>Senthil
>
>On 7/2/14 6:10 AM, "internet-drafts@ietf.org" <= ;internet-drafts@ietf.org>
>wrote:
>
>>
>>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >>has been successfully submitted by Senthil Sivakumar and posted to = the
>>IETF repository.
>>
>>Name:         draft-ietf-behave-ipfix-nat-= logging
>>Revision:     04
>>Title:                IPFIX= Information Elements for logging NAT Events
>>Document date:        2014-07-02
>>Group:                Indiv= idual Submission
>>Pages:                24 >>URL:
>>http://www.ietf.org/internet-drafts/dr= aft-ietf-behave-ipfix-nat-logging-0
>>4
>>.txt
>>Status:
>>https://datatracker.ietf.org/doc/draft-iet= f-behave-ipfix-nat-logging/
>>Htmlized:
>>http://tools.ietf.org/html/draft-ietf-behave-i= pfix-nat-logging-04
>>Diff:
>>http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-behave-ipfix-nat-logging-04
>>
>>Abstract:
>>   Network operators expect NAT devices to log events lik= e creation and
>>   deletion of translations and information about the res= ources it is
>>   managing.  The logs are essential in many cases t= o identify an
>>   attacker or a host that was used to launch malicious a= ttacks and/or
>>   for various other purposes of accounting.  Since = there is no standard
>>   way of logging this information, different NAT devices= log the
>>   information using proprietary formats and hence it is = difficult to
>>   expect a consistent behavior.  The lack of a cons= istent way to log
>>   the data makes it difficult to write the collector app= lications that
>>   would receive this data and process it to present usef= ul information.
>>   This document describes the formats for logging of NAT= events.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of >>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>

 --_000_D086E2B911C463ssenthilciscocom_-- From nobody Tue Nov 11 11:51:51 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468821A8908 for ; Tue, 11 Nov 2014 11:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSemEvcmXFg4 for ; Tue, 11 Nov 2014 11:51:37 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5B61A8903 for ; Tue, 11 Nov 2014 11:51:36 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id h11so2726496wiw.0 for ; Tue, 11 Nov 2014 11:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=81qOmbM3XNRgQa9sdvNbIbowYs2A6HfdMXHh6trXe1k=; b=qU4slm6YWfFLRjw2GENdZmnKSWPDZ5kuD4NiERJKfViDVmHaqDR5PhjQ36l0SgX0Ek kcbSIyr/Zd8ej8kZe5EVL+HV4LaDqcvGM3CC5eQx5YGw1/PREOs6cIpmNGHd3xthWlM7 dnMydThxejJkXyoNRVaai70TGzVZxoB+y66KeDhW8hpTePTXrkJj+JukM+HT38OORjgD 3crnnV7E3Ym1v5K+udjLME773tSFy6fAnSaHz5m0hu5dfQxhU/4AYBH5/eHUvbEnlJ3y NzCKmKIYHr2/0l0UWf7VK1S4ABasqNCDhQlwvpBAFXB1gRBVQQy8pP02OMuJ32gtja5Q KdhA== X-Received: by 10.180.198.230 with SMTP id jf6mr21947777wic.42.1415735495366; Tue, 11 Nov 2014 11:51:35 -0800 (PST) Received: from ?IPv6:2001:67c:370:168:858f:dac0:72a2:f7ac? (t2001067c03700168858fdac072a2f7ac.wireless-1x.v6.meeting.ietf.org. [2001:67c:370:168:858f:dac0:72a2:f7ac]) by mx.google.com with ESMTPSA id h8sm28543515wjs.43.2014.11.11.11.51.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 11:51:34 -0800 (PST) Message-ID: <546268C2.5040900@gmail.com> Date: Tue, 11 Nov 2014 13:51:30 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080601050603000608070806" Archived-At: http://mailarchive.ietf.org/arch/msg/behave/8rOSnPSHCtoWv0CRUjUfi9lFw5k Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:51:48 -0000 This is a multi-part message in MIME format. --------------080601050603000608070806 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/10/2014 08:47 PM, Senthil Sivakumar (ssenthil) wrote: > No, I am not in Honolulu. Like Tom said I can be available for a phone > call. That could be useful, but what I'm most curious about, is one question. When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty hard to stay in sync. When I got publication requests for these three drafts, I asked if there was an obvious one to process first, and got back that I should do the MIB draft first, rather than sending them through as a set and trying to keep them in sync. Is that still the right plan? Or is the conversation Tom and Dave Harrington are having specific to the MIB draft, and I could start work on IPFIX? Thanks, Spencer, who is really embarrassed at how bad he was at AD-sponsored! > Thanks > Senthil > > From: Spencer Dawkins at IETF > > Date: Monday, November 10, 2014 8:38 PM > To: Senthil Sivakumar > > Cc: "behave@ietf.org " >, Tom Taylor > > Subject: Re: FW: New Version Notification for > draft-ietf-behave-ipfix-nat-logging-04.txt > > Hi, Senthil, > > I'd love to talk to you about this draft (and to people about the MIB > draft, and to people about the syslog draft) this week. Are you in > Honolulu? > > Spencer > > On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) > > wrote: > > Hi Spencer, > I wanted to touch base with you to see if there are any updates on the > progress of the logging > drafts. Let us know if you are waiting on the authors on something. > > Thanks > Senthil > > On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" > > > wrote: > > >A new version of the draft is published incorporating all the > comments > >received. Please > >Let me know if you see anything that we discussed and agreed upon is > >missing. > > > >Thanks > >Senthil > > > >On 7/2/14 6:10 AM, "internet-drafts@ietf.org " > > > >wrote: > > > >> > >>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt > >>has been successfully submitted by Senthil Sivakumar and posted > to the > >>IETF repository. > >> > >>Name: draft-ietf-behave-ipfix-nat-logging > >>Revision: 04 > >>Title: IPFIX Information Elements for logging NAT > Events > >>Document date: 2014-07-02 > >>Group: Individual Submission > >>Pages: 24 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0 > >>4 > >>.txt > >>Status: > >>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ > >>Htmlized: > >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04 > >>Diff: > >>http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-ipfix-nat-logging-04 > >> > >>Abstract: > >> Network operators expect NAT devices to log events like > creation and > >> deletion of translations and information about the resources > it is > >> managing. The logs are essential in many cases to identify an > >> attacker or a host that was used to launch malicious attacks > and/or > >> for various other purposes of accounting. Since there is no > standard > >> way of logging this information, different NAT devices log the > >> information using proprietary formats and hence it is > difficult to > >> expect a consistent behavior. The lack of a consistent way > to log > >> the data makes it difficult to write the collector > applications that > >> would receive this data and process it to present useful > information. > >> This document describes the formats for logging of NAT events. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission > >>until the htmlized version and diff are available at > tools.ietf.org . > >> > >>The IETF Secretariat > >> > > > --------------080601050603000608070806 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/10/2014 08:47 PM, Senthil Sivakumar (ssenthil) wrote:
No, I am not in Honolulu. Like Tom said I can be available for a phone call.

That could be useful, but what I'm most curious about, is one question.

When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty hard to stay in sync. When I got publication requests for these three drafts, I asked if there was an obvious one to process first, and got back that I should do the MIB draft first, rather than sending them through as a set and trying to keep them in sync.

Is that still the right plan? Or is the conversation Tom and Dave Harrington are having specific to the MIB draft, and I could start work on IPFIX?

Thanks,

Spencer, who is really embarrassed at how bad he was at AD-sponsored!

Thanks
Senthil

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Monday, November 10, 2014 8:38 PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <behave@ietf.org>, Tom Taylor <tom.taylor.stds@gmail.com>
Subject: Re: FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt

Hi, Senthil,

I'd love to talk to you about this draft (and to people about the MIB draft, and to people about the syslog draft) this week. Are you in Honolulu?

Spencer

On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com> wrote:
Hi Spencer,
I wanted to touch base with you to see if there are any updates on the
progress of the logging
drafts. Let us know if you are waiting on the authors on something.

Thanks
Senthil

On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
wrote:

>A new version of the draft is published incorporating all the comments
>received. Please
>Let me know if you see anything that we discussed and agreed upon is
>missing.
>
>Thanks
>Senthil
>
>On 7/2/14 6:10 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>wrote:
>
>>
>>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt
>>has been successfully submitted by Senthil Sivakumar and posted to the
>>IETF repository.
>>
>>Name:         draft-ietf-behave-ipfix-nat-logging
>>Revision:     04
>>Title:                IPFIX Information Elements for logging NAT Events
>>Document date:        2014-07-02
>>Group:                Individual Submission
>>Pages:                24
>>URL:
>>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0
>>4
>>.txt
>>Status:
>>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/
>>Htmlized:
>>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04
>>Diff:
>>http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-ipfix-nat-logging-04
>>
>>Abstract:
>>   Network operators expect NAT devices to log events like creation and
>>   deletion of translations and information about the resources it is
>>   managing.  The logs are essential in many cases to identify an
>>   attacker or a host that was used to launch malicious attacks and/or
>>   for various other purposes of accounting.  Since there is no standard
>>   way of logging this information, different NAT devices log the
>>   information using proprietary formats and hence it is difficult to
>>   expect a consistent behavior.  The lack of a consistent way to log
>>   the data makes it difficult to write the collector applications that
>>   would receive this data and process it to present useful information.
>>   This document describes the formats for logging of NAT events.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>

--------------080601050603000608070806-- From nobody Tue Nov 11 12:50:27 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D0D1ABD3F for ; Tue, 11 Nov 2014 12:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_ASCII_ART_SPACINGc=0.833, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5a8sage7qX8 for ; Tue, 11 Nov 2014 12:50:23 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179641A9108 for ; Tue, 11 Nov 2014 12:50:21 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id tp5so12330407ieb.15 for ; Tue, 11 Nov 2014 12:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UUJ2MVf6RZSEOA2VG+hn0kuWVYxRcJluurBsvktdtzA=; b=dhGielPXYPRV/FF6BA+QCW80vetl+Y732vlrtFw6GRmws6WimS5u6oIW046iu7k41q c/kIaSeSG32sPjtvI5WeIDp96NH0xdQVTNAoeLxOzUDvbbVLEm6JPQKbGH4OixAdnIIB My3Co30fTFAHSqTSeyvjW09DggkDOs8JWVsE69wrFDl6oP5XemjATc111aApb9fctesz 6tSod/8ZYk7ztKn8gHhnptNWZEiqZAUXaHO22y5lkdo87IgvoyrojWoVupBiwO4TCgX4 mMNKg5BHqXnxgTzkyk0k4y/jgUfUDTKTlUg6eFnI36sIWfmb3qZ48f6TKpvI+sNhNT8F yHqA== X-Received: by 10.42.88.5 with SMTP id a5mr989362icm.82.1415739020350; Tue, 11 Nov 2014 12:50:20 -0800 (PST) Received: from [192.168.0.102] ([207.112.104.88]) by mx.google.com with ESMTPSA id qc7sm5946739igb.2.2014.11.11.12.50.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 12:50:20 -0800 (PST) Message-ID: <5462768C.7050407@gmail.com> Date: Tue, 11 Nov 2014 15:50:20 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Spencer Dawkins , "Senthil Sivakumar (ssenthil)" References: <546268C2.5040900@gmail.com> In-Reply-To: <546268C2.5040900@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/OUU3L9zZgw_GlWtt-RDps88Nevc Cc: "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:50:26 -0000 I gave that advice because I figured the MIB notifications in particular set the framework for some of the logs or IPFIX equivalent that had to be generated. Definitely some of the text and maybe content will be influenced by the changes now being made to the MIB. However, you could get a start on IPFIX. The events driving the notifications are going to stay the same as they are. I've tinkered with the returned objects a bit, and that should be reflected in the logs. I'd better publish my conclusions. I think our key change was to clarify what statistics we're collecting. At the NAT instance level these now are: natv2InstanceAddressMapActives Unsigned32 -- snapshot of number of address maps currently active natv2InstancePortMapActives Unsigned32 -- snapshot of number of port maps currently active natv2InstanceTranslations Counter64, -- cumulative packets translated natv2InstanceAddressMapCreations Counter64, -- cumulative address maps created natv2InstancePortMapCreations Counter64, -- cumulative port maps created natv2InstanceAddressMapActiveLimitDrops Counter64, -- cumulative packets dropped because they would have triggered the creation of an address mapping but the instance limit on total number of address maps has already been reached natv2InstancePortMapActiveLimitDrops Counter64, -- Ditto for port mapping natv2InstancePendingFragmentLimitDrops Counter64, -- Cumulative number of fragments dropped because the limit on fragments received out of order and awaiting reassembly has already been reached natv2InstanceSubscriberActiveLimitDrops Counter64, -- cumulative number of packets dropped because the packet would have triggered the creation of a mapping and the limit on number of subscribers with active mappings has already been reached natv2InstanceAddressMapFailureDrops Counter64, -- Cumulative number of packets dropped because the packet would have triggered the creation of a mapping, the mapping would have required the assignment of a new address, but none is available. I have detailed definitions of this and the next one to avoid overlap. natv2InstancePortMapFailureDrops Counter64, -- Cumulative number of packets dropped because the packet would have triggered the creation of a mapping, the mapping would have required the assignment of a new port for a given protocol, but none is available natv2InstanceOtherResourceFailureDrops Counter64, -- Cumulative number of packets dropped for some other resource-related reason. These same statistics are collected per protocol, address pool, and subscriber, to the extent that they are applicable at those levels. I did feel that Section 3 of the SYSLOG document gives a good description of the requirements IPFIX also has to meet. Tom On 11/11/2014 2:51 PM, Spencer Dawkins wrote: > On 11/10/2014 08:47 PM, Senthil Sivakumar (ssenthil) wrote: >> No, I am not in Honolulu. Like Tom said I can be available for a phone >> call. > > That could be useful, but what I'm most curious about, is one question. > > When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty > hard to stay in sync. When I got publication requests for these three > drafts, I asked if there was an obvious one to process first, and got > back that I should do the MIB draft first, rather than sending them > through as a set and trying to keep them in sync. > > Is that still the right plan? Or is the conversation Tom and Dave > Harrington are having specific to the MIB draft, and I could start work > on IPFIX? > > Thanks, > > Spencer, who is really embarrassed at how bad he was at AD-sponsored! > >> Thanks >> Senthil >> >> From: Spencer Dawkins at IETF > > >> Date: Monday, November 10, 2014 8:38 PM >> To: Senthil Sivakumar > >> Cc: "behave@ietf.org " > >, Tom Taylor > > >> Subject: Re: FW: New Version Notification for >> draft-ietf-behave-ipfix-nat-logging-04.txt >> >> Hi, Senthil, >> >> I'd love to talk to you about this draft (and to people about the MIB >> draft, and to people about the syslog draft) this week. Are you in >> Honolulu? >> >> Spencer >> >> On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) >> > wrote: >> >> Hi Spencer, >> I wanted to touch base with you to see if there are any updates on the >> progress of the logging >> drafts. Let us know if you are waiting on the authors on something. >> >> Thanks >> Senthil >> >> On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" >> > >> wrote: >> >> >A new version of the draft is published incorporating all the >> comments >> >received. Please >> >Let me know if you see anything that we discussed and agreed upon is >> >missing. >> > >> >Thanks >> >Senthil >> > >> >On 7/2/14 6:10 AM, "internet-drafts@ietf.org " >> > >> >wrote: >> > >> >> >> >>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >> >>has been successfully submitted by Senthil Sivakumar and posted >> to the >> >>IETF repository. >> >> >> >>Name: draft-ietf-behave-ipfix-nat-logging >> >>Revision: 04 >> >>Title: IPFIX Information Elements for logging NAT >> Events >> >>Document date: 2014-07-02 >> >>Group: Individual Submission >> >>Pages: 24 >> >>URL: >> >>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0 >> >>4 >> >>.txt >> >>Status: >> >>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ >> >>Htmlized: >> >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04 >> >>Diff: >> >>http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-ipfix-nat-logging-04 >> >> >> >>Abstract: >> >> Network operators expect NAT devices to log events like >> creation and >> >> deletion of translations and information about the resources >> it is >> >> managing. The logs are essential in many cases to identify an >> >> attacker or a host that was used to launch malicious attacks >> and/or >> >> for various other purposes of accounting. Since there is no >> standard >> >> way of logging this information, different NAT devices log the >> >> information using proprietary formats and hence it is >> difficult to >> >> expect a consistent behavior. The lack of a consistent way >> to log >> >> the data makes it difficult to write the collector >> applications that >> >> would receive this data and process it to present useful >> information. >> >> This document describes the formats for logging of NAT events. >> >> >> >> >> >> >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >> >>submission >> >>until the htmlized version and diff are available at >> tools.ietf.org . >> >> >> >>The IETF Secretariat >> >> >> > >> > From nobody Wed Nov 12 10:12:17 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874871A003B for ; Wed, 12 Nov 2014 10:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDDYBak8qfSX for ; Wed, 12 Nov 2014 10:11:49 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F941A9150 for ; Wed, 12 Nov 2014 10:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15191; q=dns/txt; s=iport; t=1415815893; x=1417025493; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cLUzN19H8zgLvtJSKl+v+zlBrp4uNsmgWrQOENn+p5s=; b=VnF8l5bF4SKgoqT1S61iHxfhoSAHsGg4seaScXJ24L2tG4sAKUPxTXpN FecvO4FGSU5L4mU/TWpz/yN74aZKDlpEWbs2XVwPnxkpb2S7rCcoinGHD 4wv6oItwnuXkYsCSu4j3Ow8ExCsS5/simMZTJYlD4Te0JR5Sub4np/njd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAEeiY1StJV2b/2dsb2JhbABSCoJIRlRUBQTMModNAoEdFgEBAQEBfYQCAQEBBHcCEAIBCBEDAQIoByERFAkIAgQOBQmIIwMSCAXJNg2GbgEBAQEBAQEBAQEBAQEBAQEBAQEBARQDBgGOVIFVCEsRBwmEQgWQFoIkhFOFEYITgTQ9gxKKcYZzg3xtAYEFQoEDAQEB X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208,217";a="371627399" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2014 18:11:32 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sACIBVuv012301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 18:11:31 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.48]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 12:11:31 -0600 From: "Senthil Sivakumar (ssenthil)" To: Spencer Dawkins Thread-Topic: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt Thread-Index: AQHP/VnYFHmkWST0Y0OIJ5fzEjQ1TZxcO6cAgAEij4A= Date: Wed, 12 Nov 2014 18:11:30 +0000 Message-ID: References: <546268C2.5040900@gmail.com> In-Reply-To: <546268C2.5040900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.150.39.8] Content-Type: multipart/alternative; boundary="_000_D0890C3F11C731ssenthilciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/2KBapEgwMCbM_3BBEq4YHrvjV1Q Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 18:11:59 -0000 --_000_D0890C3F11C731ssenthilciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the delay in responding, there is some dependency between mib and= logging drafts, and as far as I can tell, we did add all the relevant even= ts to the logging drafts. Going forward, we want to make sure anything that we add in the MIB that is= worth logging should be added to the logging draft, but that requires a ca= se-by-case analysis. Other than that, I don=92t think it should be strictly serialized, we can l= et them progress along, we can hold off publishing them together just to ma= ke sure they are all consistent With one another. Thanks Senthil From: Spencer Dawkins > Date: Tuesday, November 11, 2014 2:51 PM To: Senthil Sivakumar > Cc: "behave@ietf.org" >, Tom Taylor > Subject: Re: New Version Notification for draft-ietf-behave-ipfix-nat-loggi= ng-04.txt On 11/10/2014 08:47 PM, Senthil Sivakumar (ssenthil) wrote: No, I am not in Honolulu. Like Tom said I can be available for a phone call= . That could be useful, but what I'm most curious about, is one question. When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty har= d to stay in sync. When I got publication requests for these three drafts, = I asked if there was an obvious one to process first, and got back that I s= hould do the MIB draft first, rather than sending them through as a set and= trying to keep them in sync. Is that still the right plan? Or is the conversation Tom and Dave Harringto= n are having specific to the MIB draft, and I could start work on IPFIX? Thanks, Spencer, who is really embarrassed at how bad he was at AD-sponsored! Thanks Senthil From: Spencer Dawkins at IETF > Date: Monday, November 10, 2014 8:38 PM To: Senthil Sivakumar > Cc: "behave@ietf.org" >, Tom Taylor > Subject: Re: FW: New Version Notification for draft-ietf-behave-ipfix-nat-l= ogging-04.txt Hi, Senthil, I'd love to talk to you about this draft (and to people about the MIB draft= , and to people about the syslog draft) this week. Are you in Honolulu? Spencer On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) > wrote: Hi Spencer, I wanted to touch base with you to see if there are any updates on the progress of the logging drafts. Let us know if you are waiting on the authors on something. Thanks Senthil On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" > wrote: >A new version of the draft is published incorporating all the comments >received. Please >Let me know if you see anything that we discussed and agreed upon is >missing. > >Thanks >Senthil > >On 7/2/14 6:10 AM, "internet-drafts@ietf.org" > >wrote: > >> >>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >>has been successfully submitted by Senthil Sivakumar and posted to the >>IETF repository. >> >>Name: draft-ietf-behave-ipfix-nat-logging >>Revision: 04 >>Title: IPFIX Information Elements for logging NAT Events >>Document date: 2014-07-02 >>Group: Individual Submission >>Pages: 24 >>URL: >>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0 >>4 >>.txt >>Status: >>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ >>Htmlized: >>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04 >>Diff: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-ipfix-nat-logging-04 >> >>Abstract: >> Network operators expect NAT devices to log events like creation and >> deletion of translations and information about the resources it is >> managing. The logs are essential in many cases to identify an >> attacker or a host that was used to launch malicious attacks and/or >> for various other purposes of accounting. Since there is no standard >> way of logging this information, different NAT devices log the >> information using proprietary formats and hence it is difficult to >> expect a consistent behavior. The lack of a consistent way to log >> the data makes it difficult to write the collector applications that >> would receive this data and process it to present useful information. >> This document describes the formats for logging of NAT events. >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > --_000_D0890C3F11C731ssenthilciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Sorry for the delay in responding, there is some dependency between mi= b and logging drafts, and as far as I can tell, we did add all the relevant= events to the logging drafts.
Going forward, we want to make sure anything that we add in the MIB th= at is worth logging should be added to the logging draft, but that requires= a case-by-case analysis.
Other than that, I don=92t think it should be strictly serialized, we = can let them progress along, we can hold off publishing them together just = to make sure they are all consistent 
With one another.

Thanks
Senthil

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com= >
Date: Tuesday, November 11, 2014 2:= 51 PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <= behave@ietf.org>, Tom Taylor <tom.taylor.stds@gmail.com>
Subject: Re: New Version Notificati= on for draft-ietf-behave-ipfix-nat-logging-04.txt

On 11/10/2014 08:47 PM, Senthil Sivakumar (s= senthil) wrote:
No, I am not in Honolulu. Like Tom said I can be available for a phone= call.

That could be useful, but what I'm most curious about, is one question.

When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty har= d to stay in sync. When I got publication requests for these three drafts, = I asked if there was an obvious one to process first, and got back that I s= hould do the MIB draft first, rather than sending them through as a set and trying to keep them in sync.

Is that still the right plan? Or is the conversation Tom and Dave Harringto= n are having specific to the MIB draft, and I could start work on IPFIX?
Thanks,

Spencer, who is really embarrassed at how bad he was at AD-sponsored!

Thanks
Senthil

From: Spencer Dawkins at IETF <<= a moz-do-not-send=3D"true" href=3D"mailto:spencerdawkins.ietf@gmail.com">sp= encerdawkins.ietf@gmail.com>
Date: Monday, November 10, 2014 8:3= 8 PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <behave@ietf.org>, = Tom Taylor <tom.taylor.stds@gmail.com>
Subject: Re: FW: New Version Notifi= cation for draft-ietf-behave-ipfix-nat-logging-04.txt

Hi, Senthil,

I'd love to talk to you about this draft (and to people about the MIB = draft, and to people about the syslog draft) this week. Are you in Honolulu= ?

Spencer

On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com>= ; wrote:
Hi Spencer,
I wanted to touch base with you to see if there are any updates on the
progress of the logging
drafts. Let us know if you are waiting on the authors on something.

Thanks
Senthil

On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
wrote:

>A new version of the draft is published incorporating all the comments<= br> >received. Please
>Let me know if you see anything that we discussed and agreed upon is >missing.
>
>Thanks
>Senthil
>
>On 7/2/14 6:10 AM, "internet-drafts@ietf.org= " <internet-drafts@ietf.org= >
>wrote:
>
>>
>>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt >>has been successfully submitted by Senthil Sivakumar and posted to = the
>>IETF repository.
>>
>>Name:         draft-ietf-behave-ipfix-nat-= logging
>>Revision:     04
>>Title:                IPFIX= Information Elements for logging NAT Events
>>Document date:        2014-07-02
>>Group:                Indiv= idual Submission
>>Pages:                24 >>URL:
>>http://www.ie= tf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0
>>4
>>.txt
>>Status:
>>https://datatrack= er.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/
>>Htmlized:
>>http://tools.ietf.org= /html/draft-ietf-behave-ipfix-nat-logging-04
>>Diff:
>>http://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-behave-ipfix-nat-logging-04
>>
>>Abstract:
>>   Network operators expect NAT devices to log events lik= e creation and
>>   deletion of translations and information about the res= ources it is
>>   managing.  The logs are essential in many cases t= o identify an
>>   attacker or a host that was used to launch malicious a= ttacks and/or
>>   for various other purposes of accounting.  Since = there is no standard
>>   way of logging this information, different NAT devices= log the
>>   information using proprietary formats and hence it is = difficult to
>>   expect a consistent behavior.  The lack of a cons= istent way to log
>>   the data makes it difficult to write the collector app= lications that
>>   would receive this data and process it to present usef= ul information.
>>   This document describes the formats for logging of NAT= events.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of >>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>


 --_000_D0890C3F11C731ssenthilciscocom_-- From nobody Mon Nov 17 07:24:32 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505131A6F6E; Mon, 17 Nov 2014 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0J3doEnVHzj; Mon, 17 Nov 2014 07:24:27 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5981A6F7F; Mon, 17 Nov 2014 07:24:27 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so2480535ieb.23 for ; Mon, 17 Nov 2014 07:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=R0emaK9uUx7E/ZCfCRWg6sCmqYDkSj8xz3ELtlAbXbM=; b=zwH1w5r7U59dRMofDpC1V8lEBWq7I03+jjmzqPRvdHBpNA/YkhroeUlL5OvN8BgWmj Fe/SGllyfQCxu15k53sK23IdieAztrDHIuqFfsW3m7/+CiBW91NJNNnr5EIuVsnkwv1E 1hyWdvme1CwSVJwDsxGAXeuIur03DQvcJtrlPi9LDUVp8Xb4a0+QDJukkcn5uurX59Ep t0buEPbyouxAFenmQBm2u5uL3bDY7FipVkMMGXkKUK1zblzlXvtgCWAwodhNsrQNvpP2 K5FIvFM2uaxAdnPt+8RNyOwb9TzzQ3s1XzT3QefBd3qpJjgyR5o65V3gzVluuIedK63a 0Dow== X-Received: by 10.42.142.201 with SMTP id t9mr2995030icu.60.1416237866493; Mon, 17 Nov 2014 07:24:26 -0800 (PST) Received: from [192.168.0.102] ([173.206.163.91]) by mx.google.com with ESMTPSA id rp2sm585835igb.0.2014.11.17.07.24.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 07:24:26 -0800 (PST) Message-ID: <546A1327.4090905@gmail.com> Date: Mon, 17 Nov 2014 10:24:23 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/pcOu3MihL41nv5rShEdzn6bUdGc Subject: [BEHAVE] NAT MIB: Life cycle of objects and counter persistence X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 15:24:29 -0000 Natv2-MIB has few writable objects, only for control of notifications and setting of quotas. Thus the module assumes that other means are used to provision NAT instances and address pools and configure subscriber data. It seems likely that a mechanism such as the one used to maintain the integrity of references to ifIndex will be needed to protect references to NAT instance index, address pool index, and subscriber index, but that is another topic. The basic question is how persistent the counter values supported by the Natv2-MIB should be. Apparently past practice has been to say: "until the agent restarts", but that isn't really helpful when you are trying to debug a problem. I distinguish between a counter, which is cumulative, and a state object, which gives a snapshot at the moment of reporting. Would implementors support the following general statement? "Ideally, counter values are never reset while the parent object (NAT instance, address pool, subscriber) continues to exist, even across reboots. Individual implementations may not be able to guarantee this level of persistence, and SHOULD document the circumstances under which resets could occur. In any event, all implementations MUST report the time of last reset in the relevant object in the NAT instance, address pool, and subscriber tables." By "reset" I mean setting the counter back to zero. I think that is the proper action, because it makes discontinuities more obvious than resetting to a random value. No comments mean that I will go ahead with this proposal. Tom Taylor BACKGROUND In my present thinking, the conceptual tables in the MIB module come in two groups, device level, and NAT instance level: 1. Device level: indexed by subscriber index, not by instance index (to make it easier to reassign subscribers from one NAT instance on the device to another): natv2SubscriberTable -- contains per-subscriber counters natv2SubscriberIngressInterfaceClassifierTable -- configuration data only 2. Group indexed by NAT instance, meaningful only while the instance exists: natv2InstanceTable -- now incorporates the per-instance counters, thresholds, and limits that were in separate tables before natv2NextProtocolTable -- counters per protocol supported by the NAT instance natv2PoolTable -- counters per address pool natv2PoolRangeTable -- configuration data only natv2AddressMapTable -- state data only natv2PortMapTable -- state data only From nobody Mon Nov 17 08:11:57 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF30F1A6FDE; Mon, 17 Nov 2014 08:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWyTuxluy0lj; Mon, 17 Nov 2014 08:11:42 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233F71A6F9F; Mon, 17 Nov 2014 08:11:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7AA8758; Mon, 17 Nov 2014 17:11:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XTRw3rkS75EZ; Mon, 17 Nov 2014 17:11:31 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 17 Nov 2014 17:11:33 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D4D82002C; Mon, 17 Nov 2014 17:11:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SNi-j8UG97i3; Mon, 17 Nov 2014 17:11:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F28F620013; Mon, 17 Nov 2014 17:11:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ED51A2F885E7; Mon, 17 Nov 2014 17:11:31 +0100 (CET) Date: Mon, 17 Nov 2014 17:11:31 +0100 From: Juergen Schoenwaelder To: Tom Taylor Message-ID: <20141117161131.GA79448@elstar.local> Mail-Followup-To: Tom Taylor , "behave@ietf.org" , "opsawg@ietf.org" References: <546A1327.4090905@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A1327.4090905@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/behave/ZONZQWjg7o4tKRYq6ON0rB48gxQ Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: Life cycle of objects and counter persistence X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 16:11:51 -0000 Tom, please do not talk about a counter 'reset' or resetting a counter to zero. This is not how SNMP counters work. Instead, make it clear for every Counter what the discontinuity indicator is. See Section 7.1.6 of RFC 2578: Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. The default discontinuity indicator is sysUpTime. If NAT instances can come and go dynamically, you want to specify other discontinuity indicators. /js On Mon, Nov 17, 2014 at 10:24:23AM -0500, Tom Taylor wrote: > Natv2-MIB has few writable objects, only for control of notifications > and setting of quotas. Thus the module assumes that other means are used > to provision NAT instances and address pools and configure subscriber > data. It seems likely that a mechanism such as the one used to maintain > the integrity of references to ifIndex will be needed to protect > references to NAT instance index, address pool index, and subscriber > index, but that is another topic. > > The basic question is how persistent the counter values supported by the > Natv2-MIB should be. Apparently past practice has been to say: "until > the agent restarts", but that isn't really helpful when you are trying > to debug a problem. I distinguish between a counter, which is > cumulative, and a state object, which gives a snapshot at the moment of > reporting. > > Would implementors support the following general statement? > > "Ideally, counter values are never reset while the parent object (NAT > instance, address pool, subscriber) continues to exist, even across > reboots. Individual implementations may not be able to guarantee this > level of persistence, and SHOULD document the circumstances under which > resets could occur. In any event, all implementations MUST report the > time of last reset in the relevant object in the NAT instance, address > pool, and subscriber tables." > > By "reset" I mean setting the counter back to zero. I think that is the > proper action, because it makes discontinuities more obvious than > resetting to a random value. > > No comments mean that I will go ahead with this proposal. > > Tom Taylor > > > > BACKGROUND > > In my present thinking, the conceptual tables in the MIB module come in > two groups, device level, and NAT instance level: > > 1. Device level: indexed by subscriber index, not by instance index (to > make it easier to reassign subscribers from one NAT instance on the > device to another): > > natv2SubscriberTable > -- contains per-subscriber counters > natv2SubscriberIngressInterfaceClassifierTable > -- configuration data only > > 2. Group indexed by NAT instance, meaningful only while the instance exists: > > natv2InstanceTable > -- now incorporates the per-instance counters, thresholds, and > limits that were in separate tables before > natv2NextProtocolTable > -- counters per protocol supported by the NAT instance > natv2PoolTable > -- counters per address pool > natv2PoolRangeTable > -- configuration data only > natv2AddressMapTable > -- state data only > natv2PortMapTable > -- state data only > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Nov 17 08:33:27 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD61A6FFE; Mon, 17 Nov 2014 08:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXIkDYzUbEJI; Mon, 17 Nov 2014 08:33:23 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C23C1A6FE9; Mon, 17 Nov 2014 08:33:23 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so2725854ieb.9 for ; Mon, 17 Nov 2014 08:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YFx1aHec9/XF0VpkdJLVinxtSwGO5u6nrNiRDNjN5O0=; b=QgiH75D8cbX3o9rY+u9Vwo97ySqDdxn8xCMyeKh2KEqjkoptMnMYYB3rsHC/b6twcR OrSt72RPo4oZN7hsAJg/j9Wy9E0TaRn7yvKKrygjakbBAxnSAqtUbJjr41aI7V8mGGiA 1P186ZTun4wnMp2bO+U4Z/uJijB1mUFj+/CwbLXh4wB2gNkgNO86OAZmtywiHBJLS0GF Fevu4py5aZhpeS2lBbr5W5jJqwHBKJ/yCNRpebCkSBekbMyt6rTlox5zUQj8vjcQ6bB6 8Ame/oG3wVTlCP0qbnM9aoHHAnDPWAbJwqXu8qR4GXpCf4Qpc4YXZ4EO22ujxP42Qc20 Ujhw== X-Received: by 10.50.142.33 with SMTP id rt1mr27018772igb.12.1416242002700; Mon, 17 Nov 2014 08:33:22 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-163-91.tor.primus.ca. [173.206.163.91]) by mx.google.com with ESMTPSA id mf8sm6159829igb.22.2014.11.17.08.33.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 08:33:22 -0800 (PST) Message-ID: <546A2353.6000403@gmail.com> Date: Mon, 17 Nov 2014 11:33:23 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" , Juergen Schoenwaelder References: <546A1327.4090905@gmail.com> <20141117161131.GA79448@elstar.local> In-Reply-To: <20141117161131.GA79448@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/cGp-zcbon8-nktiXW-QA8Cc61pU Subject: Re: [BEHAVE] NAT MIB: Life cycle of objects and counter persistence X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 16:33:25 -0000 OK On 17/11/2014 11:11 AM, Juergen Schoenwaelder wrote: > Tom, > > please do not talk about a counter 'reset' or resetting a counter to > zero. This is not how SNMP counters work. Instead, make it clear for > every Counter what the discontinuity indicator is. See Section 7.1.6 > of RFC 2578: > > Counters have no defined "initial" value, and thus, a single value of > a Counter has (in general) no information content. Discontinuities > in the monotonically increasing value normally occur at re- > initialization of the management system, and at other times as > specified in the description of an object-type using this ASN.1 type. > If such other times can occur, for example, the creation of an object > instance at times other than re-initialization, then a corresponding > object should be defined, with an appropriate SYNTAX clause, to > indicate the last discontinuity. Examples of appropriate SYNTAX > clause include: TimeStamp (a textual convention defined in [3]), > DateAndTime (another textual convention from [3]) or TimeTicks. > > The default discontinuity indicator is sysUpTime. If NAT instances can > come and go dynamically, you want to specify other discontinuity > indicators. > > /js > ... From nobody Mon Nov 17 10:44:54 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44981A87AE; Mon, 17 Nov 2014 10:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niipYzDpM0PO; Mon, 17 Nov 2014 10:44:47 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28111A88C7; Mon, 17 Nov 2014 10:43:29 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tr6so3489222ieb.36 for ; Mon, 17 Nov 2014 10:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8VZaIdaBU7WD6WHX8lf9eR+bCv9hWNdIaDodHj6yui4=; b=i9KbBIbfkeYybm+QOwN8zMBg1VBcAtgFtPZi678rDysNYkz2e+l9LZyPu1iLZJrRg6 9nlcnPFNS6JIpuFsf5lJOzrlLOdk9hGCKudHZGV4vjbDHF3Y6064q7jV4Wxa2fAhRGJb JB4HRyPBY/QOfj6TfGfdiYZYwvOHzzW5fozpEI9ZXgtaPpBBZwn6xcnYkjlV9KfMhsO7 jG7PcSFXKrlrLUXqT+9BIaBrcHcGIz3I8/DaFPEgRV9vzvdJO+6c8uavxYlgbU3+paKO Bu/IZ42SddIxzZddUD4x8zd41iiycWro9jVREwgzxg2fPlrR41HDIYxaBxqjlcRAxAU+ PAJg== X-Received: by 10.51.16.37 with SMTP id ft5mr27662333igd.6.1416249809052; Mon, 17 Nov 2014 10:43:29 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-163-91.tor.primus.ca. [173.206.163.91]) by mx.google.com with ESMTPSA id w197sm19256650iod.24.2014.11.17.10.43.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 10:43:28 -0800 (PST) Message-ID: <546A41D2.4040009@gmail.com> Date: Mon, 17 Nov 2014 13:43:30 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/WsrY49cahJo3Rsum7jbPi2h0WH8 Subject: [BEHAVE] NAT MIB: meaning of indexes for NAT instance, address pool, and subscriber X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 18:44:49 -0000 As I understand it, NAT instances, address pools, and subscribers could all be provisioned (and deleted) dynamically. To ensure that a given index value continues to point to information for the same object assuming that object continues to exist, I propose the following rules (adapted from RFC 2863, Interfaces MIB and taking into account the proposal in my previous E-mail): 1. The index value for a given object instance MUST remain constant between events that cause the discontinuity time for that object to be updated. (The interfaces MIB module requires constancy at least between reinitializations of the management system.) 2. After the object instance is dynamically removed, its index value MUST NOT be re-used by a *different* dynamically added object instance until after the following re-initialization of the network management system. (Same constraint as the interfaces MIB module.) DiscontinuityTime objects were part of the previous proposal and will be assumed here, since they are part of the ifIndex solution. Question to operators: should there be objects giving: -- total number of object instances (e.g., subscribers) provisioned -- next available index value -- I expect particularly useful for subscribers Comments? Tom Taylor From nobody Fri Nov 21 08:05:38 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED47E1AD53C; Fri, 21 Nov 2014 08:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuz5D-FPTIEo; Fri, 21 Nov 2014 08:05:26 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607EF1AD567; Fri, 21 Nov 2014 08:04:46 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so4905255igi.6 for ; Fri, 21 Nov 2014 08:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=sGJQiuQJF4aU10/fMrMVeL0SLouxZhQoZB2WJqnsap4=; b=TEmHjz1Vde9tFeWS4/hKU7uzOemwb8GvymTbTxw4OJlG2edDzcK18LliB+tvaac5bY 7BN1isllTQ7dun8nc6gHvBCS4/DBZGxL7hwYM0VtpI2r9YNVeKEWvq7Q21DZTG23jUme kHMWFC16RJ4PdUreMkgpeNzP+T/zH0W2IDen3XT79yaFG7yyegTJRRpLzKycsyL4JxLr bN3kUS3QTY0xBB9PzSrIPGq+Tz+IJ3fYnQtK/04aDFlCQUZZti0yzp4O4bk51ILMWpKv ErqDDAu3BXBmJIIthOmjOM6tAW/dMsaPmNgO6hXSG8BEhbbfogSrf5m03QyCkcc/gnCO u76Q== X-Received: by 10.50.3.106 with SMTP id b10mr16130822igb.41.1416585885484; Fri, 21 Nov 2014 08:04:45 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id rp2sm4418257igb.0.2014.11.21.08.04.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 08:04:45 -0800 (PST) Message-ID: <546F629F.2000801@gmail.com> Date: Fri, 21 Nov 2014 11:04:47 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/6M1DIVVQurOWS-21cVZbD1Z7FZw Subject: [BEHAVE] NAT MIB: compliance levels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:05:32 -0000 One of the issues David Harrington raised regarding the NAT MIB -11 version was what he thought might be an excessive number of compliance levels. (Issue 36, http://trac.tools.ietf.org/wg/behave/trac/wiki/MibIss036) These are the ones currently defined: (1) Basic NAT, all mappings are administered. (2) Dynamic port mappings are supported (3) Address maps and address pooling are supported (4) "Receive fragments out of order" is supported (5) Subscribers are supported I think we can combine the first with the second one. We can get rid of the fragment-related one by redefining the dropped fragment counter to count all dropped fragments and providing an object to indicate the fragmentation behaviour to help interpret the counter. This gives us three application scenarios: -- basic NAT: support of port mappings only. Objects in the natv2InstanceTable, natv2NextProtocolTable, and natv2PortMapTable are relevant. -- large-scale NAT: additional support of address pools and address maps, hence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come into the picture. -- subscriber-aware NAT: additional support of subscribers, hence natv2Subscribers and natv2SubscriberIngressInterfaceIdentifierTable are added. Comments? Tom Taylor From nobody Fri Nov 21 14:59:32 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C761A8F3B for ; Fri, 21 Nov 2014 14:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7mfCss7Cg70 for ; Fri, 21 Nov 2014 14:59:26 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A811A8BC5 for ; Fri, 21 Nov 2014 14:59:25 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so3779509lbv.7 for ; Fri, 21 Nov 2014 14:59:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YYIdnuPQu4MLYLpF9ItSf9l0qAq4u7mXCFemXRwhsQc=; b=k1X1paItQiQJYsk2YVhfpaO1247iKJytmtGjtiQDLZueB2poXMKhcpY3Kghcx2BtNQ mGMXoySmd9t0BQO/Mhqmjg5WdYS7X9s2nRcnvxRqa4G9gVsJdKok6EuqK5ODbgBylwzD frJpOwHALNJUBR/vCc+RowrCA1ISoLLS35Psexhf8gub578rLPzAqQQck2dSfNBCBVwM n2nVw7S+tMtuEBtpBRUAVKqT1NzbtzIHipBOY7TJ/0FGMrnOeCt2MUzJkgyvUsaF95zZ FdSEN7LhzBocwl+fC5Dy7rBaue0ztxpSL39GyK1aGp5LhmXBlzIWMvmjZPh/ZdZiBdEO lmUQ== X-Gm-Message-State: ALoCoQkSBYx4Bg4+3uOAKfh7B3oa76pEn6+pJ8AbuZHY3DPPiSSVbU2DrHMLncGshBz+ssEzeJ3w MIME-Version: 1.0 X-Received: by 10.152.10.67 with SMTP id g3mr8088226lab.59.1416610764497; Fri, 21 Nov 2014 14:59:24 -0800 (PST) Received: by 10.25.84.145 with HTTP; Fri, 21 Nov 2014 14:59:24 -0800 (PST) In-Reply-To: <546A41D2.4040009@gmail.com> References: <546A41D2.4040009@gmail.com> Date: Fri, 21 Nov 2014 12:59:24 -1000 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1132f4a0673e7c0508666515 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/902FjE5PMxS3-wHVzT148en56I8 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [OPSAWG] NAT MIB: meaning of indexes for NAT instance, address pool, and subscriber X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 22:59:28 -0000 --001a1132f4a0673e7c0508666515 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 17, 2014 at 8:43 AM, Tom Taylor wrote: > As I understand it, NAT instances, address pools, and subscribers could > all be provisioned (and deleted) dynamically. To ensure that a given index > value continues to point to information for the same object assuming that > object continues to exist, I propose the following rules (adapted from RFC > 2863, Interfaces MIB and taking into account the proposal in my previous > E-mail): > > 1. The index value for a given object instance MUST remain constant > between events that cause the discontinuity time for that object to be > updated. (The interfaces MIB module requires constancy at least between > reinitializations of the management system.) > > 2. After the object instance is dynamically removed, its index value MUST > NOT be re-used by a *different* dynamically added object instance until > after the following re-initialization of the network management system. > (Same constraint as the interfaces MIB module.) > > DiscontinuityTime objects were part of the previous proposal and will be > assumed here, since they are part of the ifIndex solution. > LGTM! Simon --001a1132f4a0673e7c0508666515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 17, 2014 at 8:43 AM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
As I understand it, NAT instan= ces, address pools, and subscribers=C2=A0 could all be provisioned (and del= eted) dynamically. To ensure that a given index value continues to point to= information for the same object assuming that object continues to exist, I= propose the following rules (adapted from RFC 2863, Interfaces MIB and tak= ing into account the proposal in my previous E-mail):

1. The index value for a given object instance MUST remain constant between= events that cause the discontinuity time for that object to be updated. (T= he interfaces MIB module requires constancy at least between reinitializati= ons of the management system.)

2. After the object instance is dynamically removed, its index value MUST N= OT be re-used by a *different* dynamically added object instance until afte= r the following re-initialization of the network management system. (Same c= onstraint as the interfaces MIB module.)

DiscontinuityTime objects were part of the previous proposal and will be as= sumed here, since they are part of the ifIndex solution.
=

LGTM!

Simon
--001a1132f4a0673e7c0508666515-- From nobody Fri Nov 21 16:05:46 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FF41A90F1 for ; Fri, 21 Nov 2014 16:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX20qhP8TKCN for ; Fri, 21 Nov 2014 16:05:32 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FED11A90F4 for ; Fri, 21 Nov 2014 16:05:30 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so4930471lbd.17 for ; Fri, 21 Nov 2014 16:05:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Syg5AnQ1Ck58EVZauieIERYt2Tc6bFomViwox2TBHUs=; b=h0ebvIloNGYjYSgEr77lFq8wsdrKx81ciy7BusltpQ6d5fvyf9rHLW6r7+qlsmXXeG IG0Tpg98/ODhEUyMLRE/aohfZFsehK8ZRBiByY1AP4hIV9X/EOrjBGZxt4POnw3yDyP2 oEEIadG1Z0F+fqZ83mJ9rF3DIkHLpd+jH+ONDLd2TTglMEfQ/Q/S3zhlZm6brsTJyoe4 4YBkSeh2Pg8vgkfM3WSMxtd36ixTntAU0RzFqtDKoE2wszPp/+ylRmWVqG9BF1A15uki c0KNwpXCxv8paO/3op+sRsOyu/j8MW9dY6B+n2dWWfhIzQq9J3ufjRb1zEiMDer7FV/i uj8A== X-Gm-Message-State: ALoCoQkVK9W4om6I84gbP6AE8nADcArY1PWwewMi+PA8KuFh6tMOfT/HnNYu1Ud09ecKPSny+g3z MIME-Version: 1.0 X-Received: by 10.112.225.225 with SMTP id rn1mr7059208lbc.98.1416614729412; Fri, 21 Nov 2014 16:05:29 -0800 (PST) Received: by 10.25.84.145 with HTTP; Fri, 21 Nov 2014 16:05:29 -0800 (PST) In-Reply-To: <546F629F.2000801@gmail.com> References: <546F629F.2000801@gmail.com> Date: Fri, 21 Nov 2014 14:05:29 -1000 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1134dc20bb059805086751ff Archived-At: http://mailarchive.ietf.org/arch/msg/behave/7aSCDevMGBxJTQ9I-fUGJZM7ClQ Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: compliance levels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:05:35 -0000 --001a1134dc20bb059805086751ff Content-Type: text/plain; charset=UTF-8 On Fri, Nov 21, 2014 at 6:04 AM, Tom Taylor wrote: > -- basic NAT: support of port mappings only. Objects in the > natv2InstanceTable, natv2NextProtocolTable, and natv2PortMapTable > are relevant. > > -- large-scale NAT: additional support of address pools and address maps, > hence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come > into the picture. > > -- subscriber-aware NAT: additional support of subscribers, hence > natv2Subscribers and natv2SubscriberIngressInterfaceIdentifierTable > are added. > Makes sense. FYI, the IETF term for "subscriber-aware NAT" is, perhaps surprisingly, "carrier-grade NAT" [RFC6888]. Simon --001a1134dc20bb059805086751ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 21, 2014 at 6:04 AM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
-- basic NAT: support of port = mappings only. Objects in the natv2InstanceTable, natv2NextProtocolTable, a= nd natv2PortMapTable
are relevant.

-- large-scale NAT: additional support of address pools and address maps, h= ence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come int= o the picture.

-- subscriber-aware NAT: additional support of subscribers, hence natv2Subs= cribers and natv2SubscriberIngressInterfaceIdentifierTable
are added.

Makes sense.

FYI, the IETF term for "= subscriber-aware NAT" is, perhaps surprisingly, "carrier-grade NA= T" [RFC6888].

Simon
--001a1134dc20bb059805086751ff-- From nobody Mon Nov 24 08:30:42 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A731A86F6; Mon, 24 Nov 2014 08:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ9SS6Pr0G1s; Mon, 24 Nov 2014 08:30:35 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D2B1A711A; Mon, 24 Nov 2014 08:30:34 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so9209999ieb.9 for ; Mon, 24 Nov 2014 08:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=8s2pcBqONUrOswd+9RduYR86056WJT1AwfoLNRDMDVE=; b=HMyB5FnqUUC+pWxPZEebJ+W+sJUGIt1u8OUptc/V6mA94dbb/cDj6ls4D8vpQtlpFw Wmk/0Avj1tqNREfs4L5Zx4BgBjMJKy5mnqTigoWIwGISu/ENrLDfTpH6/0pid0kMhpiA RB2UYShYg8pef5M0Di6rJmA05DoMkfKK8rKV/3UBJWqIj7trCNU/RpFtgBOccaVjcd3w +rHGi+ezpmW1Jc+T8H1PJgGycmV6/YFFe94qp5t0v0/64ie1zPV7eg+S4zS4VHZ/+S3D kxG5qB8WuGcx5OU3+k8d2yJqDxdBg3Zbhxv/yVkKVIARqWjHCrN7C+/e0XBImfVFsIlK bZFQ== X-Received: by 10.50.8.71 with SMTP id p7mr12513903iga.9.1416846633775; Mon, 24 Nov 2014 08:30:33 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id ro6sm4721864igb.3.2014.11.24.08.30.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 08:30:33 -0800 (PST) Message-ID: <54735D29.7050308@gmail.com> Date: Mon, 24 Nov 2014 11:30:33 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/OsLmll8ajbq3vkFJJk8VH0Q_C50 Subject: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:30:36 -0000 The published version -11 of the NAT MIB module indexes address maps by NAT instance, internal realm, and internal address. This works fine, I think, except in the CGN case where packets originated by the subscriber come in by way of tunnels. Take DS-Lite as an example. In the case of DS-Lite, the realm actually defines an IPv6 numbering space -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets originated by the subscriber certainly won't be unique over the realm, making nonsense of the definition of realm as defining a numbering space. I see two possible ways to present the address map in the MIB module. One is to keep things as they are, but add a note that the operator may want to filter on subscriber index (which is part of the mapping information) to select the information they really want. If they are starting with the IPv6 tunnel source address, they have to go to the subscriber table to get the corresponding subscriber index, then use that to filter the map data. The other possible solution is to index the map data by the "internal realm address" (which would be the IPv6 tunnel source address) and present the internal packet source address (which would be the reserved 192.0.0.2) separately in the mapping table. Except in the case of tunneling, the two addresses will be the same, so there is redundancy in most cases. However, the workflow for tracing back from a tunnel source address would be simplified. Comments? Preferences? Tom Taylor From nobody Mon Nov 24 10:13:31 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661D11A87AE for ; Mon, 24 Nov 2014 10:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U41PflDhDz_q for ; Mon, 24 Nov 2014 10:13:27 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FC91A8791 for ; Mon, 24 Nov 2014 10:13:27 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gf13so8222324lab.28 for ; Mon, 24 Nov 2014 10:13:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oQnZ0JFYDjLj7sqZh0Y0WwScoDYmMqsFjOCOoXFcyCA=; b=AQ0GRNlChQLXn9JfTPuu2w/Yr1gs5B38Kpq4Kf3MKR+iACrk+otnI8HkoFbO7f7T4i HMtEY2KtqmpB2g+xE6ctuxJHT9oK2kiDkSLzD8uN2O5M11cwQ9xwGApwc690VE+bJPnM 0+CSB7+ULJs6DZ4yvSjXOMu5KmCNlMmUEoocjwZeiOdotzDZ07SaNswxGblIwTpz0Lwn dxDpYN7LKyZ4qlXNlvN2Qm6fjwdvcXTE6uutDgD1k/ZtZu/bZWKfuAeTYryogWZVF0Qs ebcIawcId2wqm/SCixS42eWaM0zj0AZAHQviLngJ1RoI81Q9vVJYO8fWOuk6p9FO1yU+ zKfw== X-Gm-Message-State: ALoCoQnW8QF5ipXck1PcTLkrDBJ/Phn60bSL+g+lAI5/TuyGk/cRlODCGn8YL6fYV60SZU77eLrt MIME-Version: 1.0 X-Received: by 10.152.243.37 with SMTP id wv5mr22332076lac.10.1416852805475; Mon, 24 Nov 2014 10:13:25 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 24 Nov 2014 10:13:25 -0800 (PST) In-Reply-To: <54735D29.7050308@gmail.com> References: <54735D29.7050308@gmail.com> Date: Mon, 24 Nov 2014 13:13:25 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1133f0242c32a405089ec0ad Archived-At: http://mailarchive.ietf.org/arch/msg/behave/mNaVxEMktRmHBNx9c6fv3XxIE8E Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 18:13:29 -0000 --001a1133f0242c32a405089ec0ad Content-Type: text/plain; charset=UTF-8 On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor wrote: > The published version -11 of the NAT MIB module indexes address maps by > NAT instance, internal realm, and internal address. This works fine, I > think, except in the CGN case where packets originated by the subscriber > come in by way of tunnels. Take DS-Lite as an example. > > In the case of DS-Lite, the realm actually defines an IPv6 numbering space > -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets > originated by the subscriber certainly won't be unique over the realm, > making nonsense of the definition of realm as defining a numbering space. > The definition of realm should be changed so that the tuple (internal address, subscriber index) is unique. Actually I argued in the beginning that each DS-Lite subscriber should have its own realm. That would make for a simpler model, but it turns out that that maps poorly to current implementations. That's why we have subscriber indexes now. I see two possible ways to present the address map in the MIB module. One > is to keep things as they are, but add a note that the operator may want to > filter on subscriber index (which is part of the mapping information) to > select the information they really want. If they are starting with the IPv6 > tunnel source address, they have to go to the subscriber table to get the > corresponding subscriber index, then use that to filter the map data. > Not sure what you mean. Are you suggesting a different *usage*, or actual changes to the MIB? > The other possible solution is to index the map data by the "internal > realm address" (which would be the IPv6 tunnel source address) and present > the internal packet source address (which would be the reserved 192.0.0.2) > separately in the mapping table. Except in the case of tunneling, the two > addresses will be the same, so there is redundancy in most cases. However, > the workflow for tracing back from a tunnel source address would be > simplified. > Why not just add the subscriber index to the index? Simon --001a1133f0242c32a405089ec0ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
The published version -11 of t= he NAT MIB module indexes address maps by NAT instance, internal realm, and= internal address. This works fine, I think, except in the CGN case where p= ackets originated by the subscriber come in by way of tunnels. Take DS-Lite= as an example.

In the case of DS-Lite, the realm actually defines an IPv6 numbering space = -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets o= riginated by the subscriber certainly won't be unique over the realm, m= aking nonsense of the definition of realm as defining a numbering space.

The definition of realm should be c= hanged so that the tuple (internal address, subscriber index) is unique.

Actually I argued in the beginning that each DS-Lite= subscriber should have its own realm. That would make for a simpler model,= but it turns out that that maps poorly to current implementations. That= 9;s why we have subscriber indexes now.

I see two possible ways to present the address map in the MIB module. One i= s to keep things as they are, but add a note that the operator may want to = filter on subscriber index (which is part of the mapping information) to se= lect the information they really want. If they are starting with the IPv6 t= unnel source address, they have to go to the subscriber table to get the co= rresponding subscriber index, then use that to filter the map data.

Not sure what you mean. Are you suggesti= ng a different *usage*, or actual changes to the MIB?
=C2=A0
The other possible solution is to index the map data by the "internal = realm address" (which would be the IPv6 tunnel source address) and pre= sent the internal packet source address (which would be the reserved 192.0.= 0.2) separately in the mapping table. Except in the case of tunneling, the = two addresses will be the same, so there is redundancy in most cases. Howev= er, the workflow for tracing back from a tunnel source address would be sim= plified.

Why not just add the subscri= ber index to the index?

Simon
--001a1133f0242c32a405089ec0ad-- From nobody Mon Nov 24 15:39:08 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18E91A871E; Mon, 24 Nov 2014 15:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgtX_5Q7aY_R; Mon, 24 Nov 2014 15:39:01 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6FB1A802E; Mon, 24 Nov 2014 15:39:01 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r2so4093661igi.0 for ; Mon, 24 Nov 2014 15:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ND1Fk9UuvhHn2Mr4PZT0/9qnwXzHRtzRxer0v9mXMHE=; b=JdQ7nifIGv11CERWffix85AhXsVLVCqae3fb/QxX4M9myb3IWQ8DzudqKKo9YzhvKz H8UdAiFU4GsNNo5BA2MaWGXli4TQplzsPlLUCG05mGlBwmVDPUqnc9YW+QPJeMXnPmOB i+YGer6afb5sogEMQikG+qu+K+ToyjFVfXemVoc8KG/mD9RPzJeTPBAaXDGYr5gKZ963 nCdtLy1xdxQzqgnyUlnxfKc57Wc9IpOUM6vYzdOqoJ9cf8qcH7lfXAK/flrYw+0eA423 OcDf6VuLWQyYaGnEu+KFf5dKCL0Kg9m3rFMmXx/Qk1fFe0RqiwgVIjnvXZck45Z3EmiU BTLg== X-Received: by 10.50.138.76 with SMTP id qo12mr14739679igb.43.1416872340540; Mon, 24 Nov 2014 15:39:00 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id fy5sm5225203igd.3.2014.11.24.15.38.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 15:39:00 -0800 (PST) Message-ID: <5473C191.2020101@gmail.com> Date: Mon, 24 Nov 2014 18:38:57 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/VLwxs-xAupBU54hDcTf29xcwMeQ Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:39:05 -0000 Below, with [PTT]. On 24/11/2014 1:13 PM, Simon Perreault wrote: > On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor > wrote: > >> The published version -11 of the NAT MIB module indexes address maps by >> NAT instance, internal realm, and internal address. This works fine, I >> think, except in the CGN case where packets originated by the subscriber >> come in by way of tunnels. Take DS-Lite as an example. >> >> In the case of DS-Lite, the realm actually defines an IPv6 numbering space >> -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets >> originated by the subscriber certainly won't be unique over the realm, >> making nonsense of the definition of realm as defining a numbering space. >> > > The definition of realm should be changed so that the tuple (internal > address, subscriber index) is unique. > > Actually I argued in the beginning that each DS-Lite subscriber should have > its own realm. That would make for a simpler model, but it turns out that > that maps poorly to current implementations. That's why we have subscriber > indexes now. > > I see two possible ways to present the address map in the MIB module. One >> is to keep things as they are, but add a note that the operator may want to >> filter on subscriber index (which is part of the mapping information) to >> select the information they really want. If they are starting with the IPv6 >> tunnel source address, they have to go to the subscriber table to get the >> corresponding subscriber index, then use that to filter the map data. >> > > Not sure what you mean. Are you suggesting a different *usage*, or actual > changes to the MIB? > [PTT] Different usage, just the necessary information in the description clause. Anyway, I prefer the suggestion at the end. > >> The other possible solution is to index the map data by the "internal >> realm address" (which would be the IPv6 tunnel source address) and present >> the internal packet source address (which would be the reserved 192.0.0.2) >> separately in the mapping table. Except in the case of tunneling, the two >> addresses will be the same, so there is redundancy in most cases. However, >> the workflow for tracing back from a tunnel source address would be >> simplified. >> > > Why not just add the subscriber index to the index? [PTT] Bearing in mind the application scenarios we listed the other day, I figured subscriber wouldn't always be supported. However, I've already defined a Natv2SubscriberIndexOrZero for the map, so it won't do any harm to add it to the map index. > > Simon > From nobody Thu Nov 27 10:50:09 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BFD1A0123; Thu, 27 Nov 2014 10:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qChKX1BZyBQv; Thu, 27 Nov 2014 10:50:03 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14A71A010D; Thu, 27 Nov 2014 10:50:02 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so4664098igb.17 for ; Thu, 27 Nov 2014 10:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NhyxkYtMqOHykUtZRh193o0NPHOtOPQfPylQ+vQMbfQ=; b=asz152P0yujHMTIHDQQ4Pd2PREKa6wXCimS0IYURHE0rnmvAIiLYxMg7iBHQwOz5Pn dJQHbdD5yJf+OSJ5wil4csKm6Qfuw84PgZNxITYbdsA1T6PgF+y0c74BpafI30/5qkNL 95e+WWcvqVdoJ/Ha7Dkip8LwnQw6N+AF6KvCTL140ndGOMa+Lqt2VkGHRfY3HmbZzKVG rB++wIwdgCmwGxSTAOKFEvc26ne9RdAi1S3lIPRN4AD2HWlWqh/CukbdgoHBOmLtQe2J aaETU0xIXuRBY1iGkq6i9hlDRm5AleKhV0xBGYxHAli4D9zwhrlG1gKIpe+GvdJJhkY5 DDEw== X-Received: by 10.107.162.134 with SMTP id l128mr23445828ioe.65.1417114201696; Thu, 27 Nov 2014 10:50:01 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id i184sm3878196ioi.33.2014.11.27.10.50.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 10:50:01 -0800 (PST) Message-ID: <54777259.5060202@gmail.com> Date: Thu, 27 Nov 2014 13:50:01 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/qkOb0sSMrLbXzSN0ecFCwsLvwHo Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 18:50:05 -0000 I have thought this through a bit more. One of the results is a resolution between the need to define an IPv6 realm covering some group of DS-Lite-served subscribers and your intuition that there should be a realm per subscriber. In fact, both are true simultaneously, but the scope of the IPv4 realm is limited to the tunnel in which it operates, so it isn't very interesting. What I propose at this point is as follows: natv2AddressMapInternalRealm OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Realm to which the internal address belongs. In most cases this is the realm defining the address space of the packet being translated. However, in the case of DS-Lite [RFC 6333], this realm defines the IPv6 outer header address space, while it is the inner IPv4 packet header that is remapped to the external address and realm. The corresponding IPv4 realm is restricted in scope to the tunnel, so there is no point in identifying it. Similarly, the mapped IPv4 address will normally be the well-known value 192.0.0.2, or at least lie in the reserved 192.0.0.0/29 range, and hence is not particularly interesting. If natv2AddressMapSubscriberIndex in this table is a valid subscriber index (i.e., greater than zero), then the value of natv2AddressMapInternalRealm MUST be identical to the value of natv2SubscriberRealm associated with that index." REFERENCE "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and Section 6.6 on the need to have the IPv6 tunnel address in the NAT mapping tables." ::= { natv2AddressMapEntry 2 } natv2AddressMapInternalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Address type in the header of packets on the interior side of this mapping. Any value other than ipv4(1) or ipv6(2) would be unexpected. In the DS-Lite case, the address type is ipv6(2). The mapping in that case is considered to be from the combination of the IPv6 tunnel source address and the well-known IPv4 inner source address (which is not presented in this table) to the external address." REFERENCE "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and Section 6.6 on the need to have the IPv6 tunnel address in the NAT mapping tables." ::= { natv2AddressMapEntry 3 } natv2AddressMapInternalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source address of packets originating from the interior of the association provided by this mapping. In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel source address. In this case, the mapping is considered to be from the combination of the tunnel source address and the well-known IPv4 inner source address (which is not presented in this table) to the external address." REFERENCE "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and Section 6.6 on the need to have the IPv6 tunnel address in the NAT mapping tables." ::= { natv2AddressMapEntry 4 } Tom Taylor On 24/11/2014 1:13 PM, Simon Perreault wrote: > > On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor > wrote: > > The published version -11 of the NAT MIB module indexes address maps > by NAT instance, internal realm, and internal address. This works > fine, I think, except in the CGN case where packets originated by > the subscriber come in by way of tunnels. Take DS-Lite as an example. > > In the case of DS-Lite, the realm actually defines an IPv6 numbering > space -- the reserved IPv4 address 192.0.0.2 appearing as the source > of packets originated by the subscriber certainly won't be unique > over the realm, making nonsense of the definition of realm as > defining a numbering space. > > > The definition of realm should be changed so that the tuple (internal > address, subscriber index) is unique. > > Actually I argued in the beginning that each DS-Lite subscriber should > have its own realm. That would make for a simpler model, but it turns > out that that maps poorly to current implementations. That's why we have > subscriber indexes now. > > I see two possible ways to present the address map in the MIB > module. One is to keep things as they are, but add a note that the > operator may want to filter on subscriber index (which is part of > the mapping information) to select the information they really want. > If they are starting with the IPv6 tunnel source address, they have > to go to the subscriber table to get the corresponding subscriber > index, then use that to filter the map data. > > > Not sure what you mean. Are you suggesting a different *usage*, or > actual changes to the MIB? > > The other possible solution is to index the map data by the > "internal realm address" (which would be the IPv6 tunnel source > address) and present the internal packet source address (which would > be the reserved 192.0.0.2) separately in the mapping table. Except > in the case of tunneling, the two addresses will be the same, so > there is redundancy in most cases. However, the workflow for tracing > back from a tunnel source address would be simplified. > > > Why not just add the subscriber index to the index? > > Simon From nobody Thu Nov 27 10:56:28 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0123C1A013B for ; Thu, 27 Nov 2014 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy1gcHEhGCX2 for ; Thu, 27 Nov 2014 10:56:23 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A981A0140 for ; Thu, 27 Nov 2014 10:56:23 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so4541715lbv.14 for ; Thu, 27 Nov 2014 10:56:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9T2zqYvBkgsbvZSUJEMztSduDJsu2tbi+PhG8ymSJ/A=; b=DriQ8QMOoosxFmCduXBoucGCdvqlWPWCWCqY7ZFQgvtGd4XMtnp96W8HfZvu+Ygyoe emPF/amzq5v+hYl8hQ6fK/IET/Mts7h/H6DS+BxKiPZwBbdd0v+d3Ae+bXjdW2Xj38Gp q8encuUVqK0Pk7oazFcjNOsMtzqUP2iOCZ3zLfJ8zPd0j4nj+nOAgMSac2MKleEWz7DJ 4SBNKBRveL+BBkdkph8UmWZPvfnSCkS9xwffxbLTxn6BoaieqdAOIFw17JqqnNrHukol WjC8yhUg+dZQhuPDLUmnVfXXY58pQL3IlZxUNSi6xtiZSPg6yT6fcOB9la4ra+i37vjO VdXw== X-Gm-Message-State: ALoCoQnzhbItq1wgfPV5SysGMNjuOXeDKF3zJ1dfvlCm5WELhxZgfeg2QdPAdot93GQj8sA+XK+C MIME-Version: 1.0 X-Received: by 10.112.219.227 with SMTP id pr3mr36895956lbc.63.1417114581283; Thu, 27 Nov 2014 10:56:21 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 27 Nov 2014 10:56:21 -0800 (PST) In-Reply-To: <54777259.5060202@gmail.com> References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> Date: Thu, 27 Nov 2014 13:56:21 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c334123957060508dbb331 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/SjdPElRbJ7YBjqNOAdTnkF3doh0 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 18:56:26 -0000 --001a11c334123957060508dbb331 Content-Type: text/plain; charset=UTF-8 Ok so if I understand correctly, you replace the IPv4 --> IPv4 address mapping with the IPv6 --> IPv4 address mapping in the case of DS-Lite. If that's right, then I don't see how it could work. There is not necessarily such an IPv6 --> IPv4 address mapping. The internal 192.0.0.0/29 addresses could be mapped to different external IPv4 addresses. Or maybe I misunderstood your proposal... Simon On Thu, Nov 27, 2014 at 1:50 PM, Tom Taylor wrote: > I have thought this through a bit more. One of the results is a resolution > between the need to define an IPv6 realm covering some group of > DS-Lite-served subscribers and your intuition that there should be a realm > per subscriber. In fact, both are true simultaneously, but the scope of the > IPv4 realm is limited to the tunnel in which it operates, so it isn't very > interesting. > > What I propose at this point is as follows: > > natv2AddressMapInternalRealm OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Realm to which the internal address belongs. In most cases > this is the realm defining the address space of the packet > being translated. However, in the case of DS-Lite [RFC > 6333], this realm defines the IPv6 outer header address > space, while it is the inner IPv4 packet header that is > remapped to the external address and realm. The > corresponding IPv4 realm is restricted in scope to the > tunnel, so there is no point in identifying it. Similarly, > the mapped IPv4 address will normally be the well-known > value 192.0.0.2, or at least lie in the reserved > 192.0.0.0/29 range, and hence is not particularly > interesting. > > If natv2AddressMapSubscriberIndex in this table is a valid > subscriber index (i.e., greater than zero), then the value > of natv2AddressMapInternalRealm MUST be identical to the > value of natv2SubscriberRealm associated with that index." > REFERENCE > "DS-Lite: RFC 6333, Section 5.7 for well-known addresses > and Section 6.6 on the need to have the IPv6 tunnel address > in the NAT mapping tables." > ::= { natv2AddressMapEntry 2 } > > natv2AddressMapInternalAddressType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Address type in the header of packets on the > interior side of this mapping. Any value other than ipv4(1) > or ipv6(2) would be unexpected. > > In the DS-Lite case, the address type is ipv6(2). The > mapping in that case is considered to be from the > combination of the IPv6 tunnel source address and the > well-known IPv4 inner source address (which is not presented > in this table) to the external address." > REFERENCE > "DS-Lite: RFC 6333, Section 5.7 for well-known addresses > and Section 6.6 on the need to have the IPv6 tunnel address > in the NAT mapping tables." > ::= { natv2AddressMapEntry 3 } > > natv2AddressMapInternalAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Source address of packets originating from the interior > of the association provided by this mapping. > > In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel > source address. In this case, the mapping is considered to > be from the combination of the tunnel source address and the > well-known IPv4 inner source address (which is not presented > in this table) to the external address." > REFERENCE > "DS-Lite: RFC 6333, Section 5.7 for well-known addresses > and Section 6.6 on the need to have the IPv6 tunnel address > in the NAT mapping tables." > ::= { natv2AddressMapEntry 4 } > > Tom Taylor > > On 24/11/2014 1:13 PM, Simon Perreault wrote: > >> >> On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor > > wrote: >> >> The published version -11 of the NAT MIB module indexes address maps >> by NAT instance, internal realm, and internal address. This works >> fine, I think, except in the CGN case where packets originated by >> the subscriber come in by way of tunnels. Take DS-Lite as an example. >> >> In the case of DS-Lite, the realm actually defines an IPv6 numbering >> space -- the reserved IPv4 address 192.0.0.2 appearing as the source >> of packets originated by the subscriber certainly won't be unique >> over the realm, making nonsense of the definition of realm as >> defining a numbering space. >> >> >> The definition of realm should be changed so that the tuple (internal >> address, subscriber index) is unique. >> >> Actually I argued in the beginning that each DS-Lite subscriber should >> have its own realm. That would make for a simpler model, but it turns >> out that that maps poorly to current implementations. That's why we have >> subscriber indexes now. >> >> I see two possible ways to present the address map in the MIB >> module. One is to keep things as they are, but add a note that the >> operator may want to filter on subscriber index (which is part of >> the mapping information) to select the information they really want. >> If they are starting with the IPv6 tunnel source address, they have >> to go to the subscriber table to get the corresponding subscriber >> index, then use that to filter the map data. >> >> >> Not sure what you mean. Are you suggesting a different *usage*, or >> actual changes to the MIB? >> >> The other possible solution is to index the map data by the >> "internal realm address" (which would be the IPv6 tunnel source >> address) and present the internal packet source address (which would >> be the reserved 192.0.0.2) separately in the mapping table. Except >> in the case of tunneling, the two addresses will be the same, so >> there is redundancy in most cases. However, the workflow for tracing >> back from a tunnel source address would be simplified. >> >> >> Why not just add the subscriber index to the index? >> >> Simon >> > --001a11c334123957060508dbb331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok so if I understand correctly, you replace the IPv4 --&g= t; IPv4 address mapping with the IPv6 --> IPv4 address mapping in the ca= se of DS-Lite.

If that's right, then I don't see= how it could work. There is not necessarily such an IPv6 --> IPv4 addre= ss mapping. The internal 192.0.0.0/29 a= ddresses could be mapped to different external IPv4 addresses. Or maybe I m= isunderstood your proposal...

Simon

On Thu, Nov 27, 2014= at 1:50 PM, Tom Taylor <tom.taylor.stds@gmail.com> = wrote:
I have thought this through a bit = more. One of the results is a resolution between the need to define an IPv6= realm covering some group of DS-Lite-served subscribers and your intuition= that there should be a realm per subscriber. In fact, both are true simult= aneously, but the scope of the IPv4 realm is limited to the tunnel in which= it operates, so it isn't very interesting.

What I propose at this point is as follows:

natv2AddressMapInternalRealm OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX SnmpAdminString (SIZE(0..32))
=C2=A0 =C2=A0 MAX-ACCESS not-accessible
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Realm to which the internal address belon= gs. In most cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this is the realm defining the address sp= ace of the packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0being translated. However, in the case of= DS-Lite [RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06333], this realm defines the IPv6 outer = header address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0space, while it is the inner IPv4 packet = header that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remapped to the external address and real= m. The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0corresponding IPv4 realm is restricted in= scope to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tunnel, so there is no point in identifyi= ng it. Similarly,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the mapped IPv4 address will normally be = the well-known
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value 192.0.0.2, or at least lie in the r= eserved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0192.0.0.0/29 range, and hence is not particularly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interesting.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If natv2AddressMapSubscriberIndex in this= table is a valid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subscriber index (i.e., greater than zero= ), then the value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of natv2AddressMapInternalRealm MUST be i= dentical to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value of natv2SubscriberRealm associated = with that index."
=C2=A0 =C2=A0 REFERENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "DS-Lite: RFC 6333, Section 5.7 for well-k= nown addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Section 6.6 on the need to have the I= Pv6 tunnel address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the NAT mapping tables."
=C2=A0 =C2=A0 ::=3D { natv2AddressMapEntry 2 }

natv2AddressMapInternalAddressType OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX InetAddressType
=C2=A0 =C2=A0 MAX-ACCESS read-only
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Address type in the header of packets on = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interior side of this mapping. Any value = other than ipv4(1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or ipv6(2) would be unexpected.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the DS-Lite case, the address type is = ipv6(2). The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mapping in that case is considered to be = from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0combination of the IPv6 tunnel source add= ress and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well-known IPv4 inner source address (whi= ch is not presented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in this table) to the external address.&q= uot;
=C2=A0 =C2=A0 REFERENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "DS-Lite: RFC 6333, Section 5.7 for well-k= nown addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Section 6.6 on the need to have the I= Pv6 tunnel address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the NAT mapping tables."
=C2=A0 =C2=A0 ::=3D { natv2AddressMapEntry 3 }

natv2AddressMapInternalAddress OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX InetAddress
=C2=A0 =C2=A0 MAX-ACCESS read-only
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Source address of packets originating fro= m the interior
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the association provided by this mappi= ng.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the case of DS-Lite [RFC 6333], this i= s the IPv6 tunnel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source address. In this case, the mapping= is considered to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be from the combination of the tunnel sou= rce address and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well-known IPv4 inner source address (whi= ch is not presented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in this table) to the external address.&q= uot;
=C2=A0 =C2=A0 REFERENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "DS-Lite: RFC 6333, Section 5.7 for well-k= nown addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Section 6.6 on the need to have the I= Pv6 tunnel address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the NAT mapping tables."
=C2=A0 =C2=A0 ::=3D { natv2AddressMapEntry 4 }

Tom Taylor

On 24/11/2014 1:13 PM, Simon Perreault wrote:

On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <tom.taylor.stds@gmail.com
<mailto:t= om.taylor.stds@gmail.com>> wrote:

=C2=A0 =C2=A0 The published version -11 of the NAT MIB module indexes addre= ss maps
=C2=A0 =C2=A0 by NAT instance, internal realm, and internal address. This w= orks
=C2=A0 =C2=A0 fine, I think, except in the CGN case where packets originate= d by
=C2=A0 =C2=A0 the subscriber come in by way of tunnels. Take DS-Lite as an = example.

=C2=A0 =C2=A0 In the case of DS-Lite, the realm actually defines an IPv6 nu= mbering
=C2=A0 =C2=A0 space -- the reserved IPv4 address 192.0.0.2 appearing as the= source
=C2=A0 =C2=A0 of packets originated by the subscriber certainly won't b= e unique
=C2=A0 =C2=A0 over the realm, making nonsense of the definition of realm as=
=C2=A0 =C2=A0 defining a numbering space.


The definition of realm should be changed so that the tuple (internal
address, subscriber index) is unique.

Actually I argued in the beginning that each DS-Lite subscriber should
have its own realm. That would make for a simpler model, but it turns
out that that maps poorly to current implementations. That's why we hav= e
subscriber indexes now.

=C2=A0 =C2=A0 I see two possible ways to present the address map in the MIB=
=C2=A0 =C2=A0 module. One is to keep things as they are, but add a note tha= t the
=C2=A0 =C2=A0 operator may want to filter on subscriber index (which is par= t of
=C2=A0 =C2=A0 the mapping information) to select the information they reall= y want.
=C2=A0 =C2=A0 If they are starting with the IPv6 tunnel source address, the= y have
=C2=A0 =C2=A0 to go to the subscriber table to get the corresponding subscr= iber
=C2=A0 =C2=A0 index, then use that to filter the map data.


Not sure what you mean. Are you suggesting a different *usage*, or
actual changes to the MIB?

=C2=A0 =C2=A0 The other possible solution is to index the map data by the =C2=A0 =C2=A0 "internal realm address" (which would be the IPv6 t= unnel source
=C2=A0 =C2=A0 address) and present the internal packet source address (whic= h would
=C2=A0 =C2=A0 be the reserved 192.0.0.2) separately in the mapping table. E= xcept
=C2=A0 =C2=A0 in the case of tunneling, the two addresses will be the same,= so
=C2=A0 =C2=A0 there is redundancy in most cases. However, the workflow for = tracing
=C2=A0 =C2=A0 back from a tunnel source address would be simplified.


Why not just add the subscriber index to the index?

Simon

--001a11c334123957060508dbb331-- From nobody Thu Nov 27 11:06:44 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE99D1A00E9; Thu, 27 Nov 2014 11:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.309 X-Spam-Level: * X-Spam-Status: No, score=1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSao8AyZgpEc; Thu, 27 Nov 2014 11:06:41 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651171A0146; Thu, 27 Nov 2014 11:06:41 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so4968893iec.30 for ; Thu, 27 Nov 2014 11:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qaq1aVGHAg7ljaDccMZdA4MsapU7hWduY6Sjr0j2KGs=; b=hq+1o5CDv2EZETA457tEKn9fhMzoxfbccGo+YjLokgy9OtzaKp60xiAvF85+uUj/ge Hrfo0syTfrtS8pnj3M/pRCPmrroMsys3iaYg44uGV4dSFj1F5tBXrYDDR6BZiSBLGQJ4 7rZj7WO4AQEpJGCeQiNyEKDE2EnJ0bRapUJLnP3DQBrif5nXyjl8i89Eo0/8WK9Cj5RS tSrkgKd0V415kQ2Mu4yJz1aNEx/LKNyjGc+iVfPKryxNfRE9gy/51gk7/oqNG2AEfNdU 7rGEJZVlwR0leO9SiHi6sOieiHr1Uk3ENCLbu+ov+Xtr393/9VLwvz6LoTm3SrIIL7vb FtgA== X-Received: by 10.50.66.179 with SMTP id g19mr29830239igt.40.1417115200515; Thu, 27 Nov 2014 11:06:40 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id 69sm1810474ioo.28.2014.11.27.11.06.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 11:06:40 -0800 (PST) Message-ID: <5477763A.4070305@gmail.com> Date: Thu, 27 Nov 2014 14:06:34 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/hxExSm0lb5HpgqLZVVT_smViBKM Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:06:43 -0000 In the first place, you replace the IPv4 --> IPv4 mapping with {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333. Beyond that, the text I gave refers to a single mapping in the address map table. For different external IPv4 external addresses, you would be looking at different mapping instances. Tom On 27/11/2014 1:56 PM, Simon Perreault wrote: > Ok so if I understand correctly, you replace the IPv4 --> IPv4 address > mapping with the IPv6 --> IPv4 address mapping in the case of DS-Lite. > > If that's right, then I don't see how it could work. There is not > necessarily such an IPv6 --> IPv4 address mapping. The internal > 192.0.0.0/29 addresses could be mapped to > different external IPv4 addresses. Or maybe I misunderstood your proposal... > > Simon > ... From nobody Thu Nov 27 11:11:43 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E321A0154 for ; Thu, 27 Nov 2014 11:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze8oofkI50uN for ; Thu, 27 Nov 2014 11:11:40 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21081A00F4 for ; Thu, 27 Nov 2014 11:11:39 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id 10so4605642lbg.36 for ; Thu, 27 Nov 2014 11:11:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QbE/DofKLiZEXTNe71E7+TU2K8IsI+w27cLLhMkvgxY=; b=BROhu2n6HxL+JugSARd7Tb/tK3D9uivFYvEGJ8knoHXe11/+eyL2a+HhBqxLOzyuVg mugsQArH2MDENgVaYqMdepGUFaqJSQBLIJtB6GbdBUF+rSt/xIzdcysBGgiLe0Jp+9HG oz9QSpWzdt02kvpt7rR09W/2VStByym2qayE82Yx4Otb5xlQFnRO3o9LvPC0fj5VWkeg EqTA8GS4TmtjY13xmm8yZQut8ZqNFZct00V7m2Jfq7MiLub/xuE7WKUgcv1MnfYvCnnk 2L5F5eLzczhHQp1qHbGpZL2lNdiLIl/bF9DuVCDj6edUM6WaGNOr9gsu0Z53KjSkWXLR qKfA== X-Gm-Message-State: ALoCoQlryJOCv53iqyNltfWiYMnRLtQ7+7OKPyVEXzaSfhcuJ+4Mm/ONzorqi58p/9Rj+lmiW185 MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr40898278lbb.6.1417115498099; Thu, 27 Nov 2014 11:11:38 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 27 Nov 2014 11:11:38 -0800 (PST) In-Reply-To: <5477763A.4070305@gmail.com> References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> Date: Thu, 27 Nov 2014 14:11:38 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c341c8decbc10508dbe94b Archived-At: http://mailarchive.ietf.org/arch/msg/behave/AD9exBswI4JV_RxkIF6hciYiTPw Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:11:41 -0000 --001a11c341c8decbc10508dbe94b Content-Type: text/plain; charset=UTF-8 On Thu, Nov 27, 2014 at 2:06 PM, Tom Taylor wrote: > In the first place, you replace the IPv4 --> IPv4 mapping with > {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333. > I understand that, but I don't see how the proposed MIB text does that. Beyond that, the text I gave refers to a single mapping in the address map > table. For different external IPv4 external addresses, you would be looking > at different mapping instances. > Can you please give an example with numbers showing how a DS-Lite address mapping would be represented in the MIB? Thanks, Simon --001a11c341c8decbc10508dbe94b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 27, 2014 at 2:06 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
In the first place, you replac= e the IPv4 --> IPv4 mapping with
{IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333.

I understand that, but I don't see how th= e proposed MIB text does that.

Beyond that, the text I gave refers to a single mapping in the address map = table. For different external IPv4 external addresses, you would be looking= at different mapping instances.

Can you please= give an example with numbers showing how a DS-Lite address mapping would b= e represented in the MIB?

Thanks,
Simon
--001a11c341c8decbc10508dbe94b-- From nobody Thu Nov 27 11:23:43 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BDD1A015F; Thu, 27 Nov 2014 11:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLZ5RE8GHySR; Thu, 27 Nov 2014 11:23:12 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4521C1A0173; Thu, 27 Nov 2014 11:23:12 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so4707303igd.13 for ; Thu, 27 Nov 2014 11:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=L5ecvSXZoG3MUXlcz/+k0oHOY1MTv3jyLcSWcDoS++o=; b=zCGnGnQt+sl9UhkZu1mBRzvE3HyjiwMGVNG6pkXE0RfOHY/JV3gk3nn38TKu0TyZdq kXjr2vdL9dJsZM/YzbQ+HL0U5km5+fBfY/D1igy+IZsek0fkmYOHADjDHhr48XKhb8yD kdbey4nbpOEZP71NlWrXWhZwIZmTjj2fIUPY9OQaIkcb9q8V8Poh9059tTltVHbM0muk JxCGgnRCroh6XkOQmK/JvCW4wq0bXH4CgZCzmS/zuJvoTd5pprkEoMgiuxxvQB4NKBEG 9dhOcDVvHLNcOjeUhndsG9hgPrDfdu6Lt91C5HexPtzdOulPUsGwGVeX22teDxcRgL53 tsHQ== X-Received: by 10.50.78.164 with SMTP id c4mr14916529igx.1.1417116191251; Thu, 27 Nov 2014 11:23:11 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id jg3sm968251igb.12.2014.11.27.11.23.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 11:23:10 -0800 (PST) Message-ID: <54777A19.4010409@gmail.com> Date: Thu, 27 Nov 2014 14:23:05 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/keEkvuR3WVLBBQzGfRKsRo-4cBM Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:23:23 -0000 Just to set the agenda: the definition of the address mapping table entry: natv2AddressMapEntry OBJECT-TYPE SYNTAX Natv2AddressMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mapping from internal to external address." INDEX { natv2AddressMapInstanceIndex, natv2AddressMapInternalRealm, natv2AddressMapInternalAddressType, natv2AddressMapInternalAddress } ::= { natv2AddressMapTable 1 } Natv2AddressMapEntry ::= SEQUENCE { natv2AddressMapInstanceIndex Natv2InstanceIndex, natv2AddressMapInternalRealm SnmpAdminString, natv2AddressMapInternalAddressType InetAddressType, natv2AddressMapInternalAddress InetAddress, natv2AddressMapExternalRealm SnmpAdminString, natv2AddressMapExternalAddressType InetAddressType, natv2AddressMapExternalAddress InetAddress, natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero } Now some example numbers: natv2AddressMapInstanceIndex = 1 natv2AddressMapInternalRealm = "DS-Lite Group 5" natv2AddressMapInternalAddressType = ipv6(2) natv2AddressMapInternalAddress = 2001:db8:0:1::1 natv2AddressMapExternalRealm = "global4" natv2AddressMapExternalAddressType = ipv4(1) natv2AddressMapExternalAddress = 192.0.2.1 natv2AddressMapSubscriberIndex = 487231 This entry would be indexed by the combination of { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 } Tom On 27/11/2014 2:11 PM, Simon Perreault wrote: > On Thu, Nov 27, 2014 at 2:06 PM, Tom Taylor > wrote: > >> In the first place, you replace the IPv4 --> IPv4 mapping with >> {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333. >> > > I understand that, but I don't see how the proposed MIB text does that. > > Beyond that, the text I gave refers to a single mapping in the address map >> table. For different external IPv4 external addresses, you would be looking >> at different mapping instances. >> > > Can you please give an example with numbers showing how a DS-Lite address > mapping would be represented in the MIB? > > Thanks, > Simon > From nobody Thu Nov 27 11:38:59 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830C41A0161 for ; Thu, 27 Nov 2014 11:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJdJTeL0ziNX for ; Thu, 27 Nov 2014 11:38:54 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB41C1A015F for ; Thu, 27 Nov 2014 11:38:53 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id 10so4546926lbg.26 for ; Thu, 27 Nov 2014 11:38:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WHcvq4yCzASGioiCQSHYcBk2dCs+uh2qeBv0AWXhyhU=; b=YpqifxaFsUKcrtnYfPWCkSf5eUyCKOK9Lnkjj3Laqdi3wzMHAiRg8lplC3/3GlxUGx QoYbMaDZ9f/Logndvphr/HuU3yQfg5I8Q5bqUcjStFzVZvmny6yUUnQLaqHtILK5bfxX 8XCRMh3BY4Vhs1zY0XXf6ZSAqwoA1EF/Ti3gSv3ePAYAttdvlvRjBAAPtMOoC6jVC5OG ufkujiik2cNgOsjuDnuAEqrfZsvn2NKPK3m5nm8+A/35+i/pkg/+kkAKL6zaMtu1jJc/ NmtN8eBa0ps1kRbnqNbM3DjqF6Z3puB/mM0nIt2/FngyUbyYfXNBKXWALT58/jjbrERZ /M0Q== X-Gm-Message-State: ALoCoQmYU1w+yhjSuIK21DbEot/x5TpSeYRfQTZmxgMQIiF/CMKj8mYPoPFor97dx19GQZvy9vbk MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr40979973lbb.6.1417117131994; Thu, 27 Nov 2014 11:38:51 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 27 Nov 2014 11:38:51 -0800 (PST) In-Reply-To: <54777A19.4010409@gmail.com> References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> <54777A19.4010409@gmail.com> Date: Thu, 27 Nov 2014 14:38:51 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c341c84207180508dc4b93 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/I5uuddje5dEAZ9BMJsg5pxEmQsI Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:38:55 -0000 --001a11c341c84207180508dc4b93 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 27, 2014 at 2:23 PM, Tom Taylor wrote: > Just to set the agenda: the definition of the address mapping table entry: > > natv2AddressMapEntry OBJECT-TYPE > SYNTAX Natv2AddressMapEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Mapping from internal to external address." > INDEX { natv2AddressMapInstanceIndex, > natv2AddressMapInternalRealm, > natv2AddressMapInternalAddressType, > natv2AddressMapInternalAddress } > ::= { natv2AddressMapTable 1 } > > Natv2AddressMapEntry ::= > SEQUENCE { > natv2AddressMapInstanceIndex Natv2InstanceIndex, > natv2AddressMapInternalRealm SnmpAdminString, > natv2AddressMapInternalAddressType InetAddressType, > natv2AddressMapInternalAddress InetAddress, > natv2AddressMapExternalRealm SnmpAdminString, > natv2AddressMapExternalAddressType InetAddressType, > natv2AddressMapExternalAddress InetAddress, > natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero > } > > Now some example numbers: > > natv2AddressMapInstanceIndex = 1 > natv2AddressMapInternalRealm = "DS-Lite Group 5" > natv2AddressMapInternalAddressType = ipv6(2) > natv2AddressMapInternalAddress = 2001:db8:0:1::1 > natv2AddressMapExternalRealm = "global4" > natv2AddressMapExternalAddressType = ipv4(1) > natv2AddressMapExternalAddress = 192.0.2.1 > natv2AddressMapSubscriberIndex = 487231 > > This entry would be indexed by the combination of > > { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 } > Ok, so far this is what I expected. I see a mapping from 2001:db8:0:1::1 to 192.0.2.1. However, in DS-Lite that mapping does not necessarily exist. For example, you could have these two mappings to different external addresses simultaneously: { 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1 { 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.2.2 Note that this is the same subscriber, same IPv6 address, but different internal IPv4 addresses mapped to different external IPv4 addresses. As you can see there is no unique mapping IPv6 --> IPv4. Simon --001a11c341c84207180508dc4b93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 27, 2014 at 2:23 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
Just to set the agenda: the de= finition of the address mapping table entry:

natv2AddressMapEntry OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX Natv2AddressMapEntry
=C2=A0 =C2=A0 MAX-ACCESS not-accessible
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Mapping from internal to external address= ."
=C2=A0 =C2=A0 INDEX { natv2AddressMapInstanceIndex,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalRealm,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddress= Type,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddress }<= br> =C2=A0 =C2=A0 ::=3D { natv2AddressMapTable 1 }

Natv2AddressMapEntry ::=3D
=C2=A0 =C2=A0 SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInstanceIndex=C2=A0 =C2=A0 =C2= =A0 =C2=A0Natv2InstanceIndex,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalRealm=C2=A0 =C2=A0 =C2= =A0 =C2=A0SnmpAdminString,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddressType InetA= ddressType,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddress=C2=A0 =C2=A0 =C2= =A0InetAddress,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapExternalRealm=C2=A0 =C2=A0 =C2= =A0 =C2=A0SnmpAdminString,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapExternalAddressType InetA= ddressType,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapExternalAddress=C2=A0 =C2=A0 =C2= =A0InetAddress,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapSubscriberIndex=C2=A0 =C2=A0 =C2= =A0Natv2SubscriberIndexOrZero
=C2=A0 =C2=A0 }

Now some example numbers:

natv2AddressMapInstanceIndex=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 1
natv2AddressMapInternalRealm=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D "DS-Lite Gr= oup 5"
natv2AddressMapInternalAddressType =3D ipv6(2)
natv2AddressMapInternalAddress=C2=A0 =C2=A0 =C2=A0=3D 2001:db8:0:1::1
natv2AddressMapExternalRealm=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D "global4&qu= ot;
natv2AddressMapExternalAddressType =3D ipv4(1)
natv2AddressMapExternalAddress=C2=A0 =C2=A0 =C2=A0=3D 192.0.2.1
natv2AddressMapSubscriberIndex=C2=A0 =C2=A0 =C2=A0=3D 487231

This entry would be indexed by the combination of

{ 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 }

Ok, so far this is what I expected. I see a mapping from 2001= :db8:0:1::1 to 192.0.2.1. However, in DS-Lite that mapping does not necessa= rily exist. For example, you could have these two mappings to different ext= ernal addresses simultaneously:

<= div class=3D"gmail_extra">{ 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1
{ 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.= 2.2

No= te that this is the same subscriber, same IPv6 address, but different inter= nal IPv4 addresses mapped to different external IPv4 addresses. As you can = see there is no unique mapping IPv6 --> IPv4.

Simon
--001a11c341c84207180508dc4b93-- From nobody Thu Nov 27 11:45:16 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BEF1A017E; Thu, 27 Nov 2014 11:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC14IkSVIwYA; Thu, 27 Nov 2014 11:45:06 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E051A0181; Thu, 27 Nov 2014 11:45:04 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so5003366ieb.37 for ; Thu, 27 Nov 2014 11:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=faUedEa63CTzG6+pwhJ0V3DMbjfp4dbxxltw0aV5waw=; b=MuTkuWQV5Ci6cSgIGDFCe2uQw6ieTrgp4PqZ8xpHl6IgeMS6f0QpOlATC9ywfGcYdY CCw8xHsNqJ3ket087To2gtB64FzOlIFo8NzRc5DAOFyJNjuqpfuZPh1N6N3y/tAyShgx d/gNE+L1VZ9LUCoqWUuxZmMHathly9OFfcW3BzzpBHw6j6RQMLv5wDnBhGi8AJi+rKov VppAub3Aq/i8PqRFAkI6tMQDlT2/XOMXU0SC22w3hlH2gewlXeFY97Z9fp7x+BCFqMZH wxSvhVhgYNHTKRb7ObKjJFRIf8uB99sQzh/XWHM+eJxjTQGbLveOe9ABmK7i/mmuIheW wugg== X-Received: by 10.107.135.211 with SMTP id r80mr35257790ioi.67.1417117503650; Thu, 27 Nov 2014 11:45:03 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id g139sm3940223iog.41.2014.11.27.11.45.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 11:45:03 -0800 (PST) Message-ID: <54777F39.1010901@gmail.com> Date: Thu, 27 Nov 2014 14:44:57 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> <54777A19.4010409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/N0ha2xOOu84I9Bu8TRjPSCTXNCw Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: index for retrieval of address maps X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:45:12 -0000 Below. On 27/11/2014 2:38 PM, Simon Perreault wrote: > On Thu, Nov 27, 2014 at 2:23 PM, Tom Taylor > wrote: > >> Just to set the agenda: the definition of the address mapping table entry: >> >> natv2AddressMapEntry OBJECT-TYPE >> SYNTAX Natv2AddressMapEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Mapping from internal to external address." >> INDEX { natv2AddressMapInstanceIndex, >> natv2AddressMapInternalRealm, >> natv2AddressMapInternalAddressType, >> natv2AddressMapInternalAddress } >> ::= { natv2AddressMapTable 1 } >> >> Natv2AddressMapEntry ::= >> SEQUENCE { >> natv2AddressMapInstanceIndex Natv2InstanceIndex, >> natv2AddressMapInternalRealm SnmpAdminString, >> natv2AddressMapInternalAddressType InetAddressType, >> natv2AddressMapInternalAddress InetAddress, >> natv2AddressMapExternalRealm SnmpAdminString, >> natv2AddressMapExternalAddressType InetAddressType, >> natv2AddressMapExternalAddress InetAddress, >> natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero >> } >> >> Now some example numbers: >> >> natv2AddressMapInstanceIndex = 1 >> natv2AddressMapInternalRealm = "DS-Lite Group 5" >> natv2AddressMapInternalAddressType = ipv6(2) >> natv2AddressMapInternalAddress = 2001:db8:0:1::1 >> natv2AddressMapExternalRealm = "global4" >> natv2AddressMapExternalAddressType = ipv4(1) >> natv2AddressMapExternalAddress = 192.0.2.1 >> natv2AddressMapSubscriberIndex = 487231 >> >> This entry would be indexed by the combination of >> >> { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 } >> > > Ok, so far this is what I expected. I see a mapping from 2001:db8:0:1::1 to > 192.0.2.1. However, in DS-Lite that mapping does not necessarily exist. For > example, you could have these two mappings to different external addresses > simultaneously: > > { 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1 > { 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.2.2 > > Note that this is the same subscriber, same IPv6 address, but different > internal IPv4 addresses mapped to different external IPv4 addresses. As you > can see there is no unique mapping IPv6 --> IPv4. > > Simon > [PTT] If this is true for a single NAT instance, then I have to add the mapped address to the table. I see Section 5.7 is open on the subject, so I'll do so. Thanks, Tom