From nobody Wed Jul 1 17:06:34 2015 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 1D17C1B2C62 for ; Wed, 1 Jul 2015 17:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 xZfjU0URNmiy; Wed, 1 Jul 2015 17:06:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 723C61B2C61; Wed, 1 Jul 2015 17:06:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702000628.5751.24779.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 17:06:28 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 00:06:33 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Wed Jul 1 23:06:28 2015 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 007591B2F5A for ; Wed, 1 Jul 2015 23:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 ZO3CKIT_T59B; Wed, 1 Jul 2015 23:06:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C38911B2F54; Wed, 1 Jul 2015 23:06:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702060626.10975.2072.idtracker@ietfa.amsl.com> Date: Wed, 01 Jul 2015 23:06:26 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 06:06:28 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Thu Jul 2 09:10:56 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8B74B1B2C2D; Wed, 1 Jul 2015 16:26:08 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FDA1B2C2E for ; Wed, 1 Jul 2015 16:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] 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 0tyqSPfWp8d9 for ; Wed, 1 Jul 2015 16:26:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0011B2C21 for ; Wed, 1 Jul 2015 16:26:07 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:53472 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAROH-00038W-RR for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Wed, 01 Jul 2015 16:26:06 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t61NQ0PO020261 for ; Wed, 1 Jul 2015 23:26:00 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 1161DC207E6; Wed, 1 Jul 2015 23:26:00 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #830007 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 01 Jul 2015 23:26:00 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150701232607.1C0011B2C21@ietfa.amsl.com> Resent-Date: Wed, 1 Jul 2015 16:26:07 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 09:10:54 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: [BEHAVE] [IANA #830007] Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval@iana.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 23:26:08 -0000 Dear Authors: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We've completed the IANA Actions for the following RFC-to-be: draft-perrault-behave-deprecate-nat-mib-v1-04 IANA has updated the mib-2 registration associated with value 123 to read as follows: 123 natMIB (OBSOLETE) NAT-MIB [RFC-perrault-behave-deprecate-nat-mib-v1-05] Please see http://www.iana.org/assignments/smi-numbers Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) We'll update the reference when the RFC Editor notifies us that they've assigned a number. Thanks, Amanda Baber IANA Senior Specialist ICANN From nobody Thu Jul 2 09:10:57 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 691571B2C63; Wed, 1 Jul 2015 17:08:56 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ADA1B2C62 for ; Wed, 1 Jul 2015 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 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_SOFTFAIL=0.665] 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 l2jC1BV3oB5c for ; Wed, 1 Jul 2015 17:08:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF211B2C60 for ; Wed, 1 Jul 2015 17:08:52 -0700 (PDT) Received: from mail-ig0-x231.google.com ([2607:f8b0:4001:c05::231]:35741) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAS3f-00066r-B4 for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Wed, 01 Jul 2015 17:08:51 -0700 Received: by igblr2 with SMTP id lr2so109167945igb.0 for ; Wed, 01 Jul 2015 17:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=+c2RcfR2neyx6mqNiX9prjguDDeC+nbOcKHjWOMmd3E=; b=qgUwQDiBjFCqMDRQoXSPOGsHc1YdPvxI0cFzUD1UVJTD2L05iqxEFi+UQVo7iZ8AuC 5foy7KYFcUOSABXHhE7CcJVHpOzC2WY9EPC21J3T4+x042/Jecv0goZgubfpjEtFJ63w MFvKmAP3FEip1fF5xQLq9dUiHPG7XPaLVYaWq4SW6PtxfKaiM1lFI4gRt1Roze5ZzRbz 8e237aEp5QXVmLvElk687qgUnf5Wx4IIbAVKXB5Qaw4Jl71CcSCai1TxC+4SgknUB2ZQ BruTi1DZKDdUl21w8lpy1zDfjBXn2Wk6UIGTW91qX94FCeoJzZ7P+bUFQeT2A1rco61w wQmQ== X-Received: by 10.50.2.3 with SMTP id 3mr37717008igq.34.1435795724338; Wed, 01 Jul 2015 17:08:44 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-6-50.tor.primus.ca. [173.206.6.50]) by smtp.gmail.com with ESMTPSA id bf10sm366912igb.12.2015.07.01.17.08.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 17:08:43 -0700 (PDT) To: drafts-approval@iana.org References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> From: Tom Taylor Message-ID: <5594810A.1040609@gmail.com> Date: Wed, 1 Jul 2015 20:08:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::231 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: tom.taylor.stds@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150702000855.1BF211B2C60@ietfa.amsl.com> Resent-Date: Wed, 1 Jul 2015 17:08:52 -0700 (PDT) Resent-From: tom.taylor.stds@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 09:10:54 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: Re: [BEHAVE] [IANA #830007] Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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: Thu, 02 Jul 2015 00:08:56 -0000 Looks ggood, thank you. Tom Taylor On 01/07/2015 7:26 PM, Amanda Baber via RT wrote: > Dear Authors: > > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > > We've completed the IANA Actions for the following RFC-to-be: > > draft-perrault-behave-deprecate-nat-mib-v1-04 > > IANA has updated the mib-2 registration associated with value 123 to read as follows: > > 123 natMIB (OBSOLETE) NAT-MIB [RFC-perrault-behave-deprecate-nat-mib-v1-05] > > Please see > http://www.iana.org/assignments/smi-numbers > > > Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) > > We'll update the reference when the RFC Editor notifies us that they've assigned a number. > > Thanks, > > Amanda Baber > IANA Senior Specialist > ICANN > > From nobody Thu Jul 2 09:10:58 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3FA481B2C92; Wed, 1 Jul 2015 17:56:05 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6331B2C88 for ; Wed, 1 Jul 2015 17:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 E9pyt1qAPaCk for ; Wed, 1 Jul 2015 17:56:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE181A0451 for ; Wed, 1 Jul 2015 17:56:04 -0700 (PDT) Received: from szxga01-in.huawei.com ([58.251.152.64]:18991) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZASnK-0005uB-8p for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Wed, 01 Jul 2015 17:56:03 -0700 Received: from 172.24.2.119 (EHLO szxeml426-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQL66731; Thu, 02 Jul 2015 08:55:23 +0800 (CST) Received: from szxeml557-mbs.china.huawei.com ([169.254.6.142]) by szxeml426-hub.china.huawei.com ([10.82.67.181]) with mapi id 14.03.0158.001; Thu, 2 Jul 2015 08:55:13 +0800 From: Tina TSOU To: Tom Taylor , "drafts-approval@iana.org" Thread-Topic: [IANA #830007] Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) Thread-Index: AQHQtFVT9Ot85Up7SEy91MTfcdMinJ3Gx7sAgACS+RA= Date: Thu, 2 Jul 2015 00:55:12 +0000 Message-ID: References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> In-Reply-To: <5594810A.1040609@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.43.15] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-SA-Exim-Connect-IP: 58.251.152.64 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: Tina.Tsou.Zouting@huawei.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150702005604.1FE181A0451@ietfa.amsl.com> Resent-Date: Wed, 1 Jul 2015 17:56:04 -0700 (PDT) Resent-From: Tina.Tsou.Zouting@huawei.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 09:10:54 -0700 Cc: "draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org" Subject: Re: [BEHAVE] [IANA #830007] Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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: Thu, 02 Jul 2015 00:56:05 -0000 RGVhciBhbGwsDQoNCkl0IGxvb2tzIGdvb2QgdG8gbWUgdG9vLg0KDQpUaGFuayB5b3UgZm9yIHlv dXIgZ3JlYXQgd29yay4NCg0KDQpUaGFuayB5b3UsDQpUaW5hDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBUb20gVGF5bG9yIFttYWlsdG86dG9tLnRheWxvci5zdGRzQGdtYWls LmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVseSAwMiwgMjAxNSAxMDowOSBBTQ0KVG86IGRyYWZ0 cy1hcHByb3ZhbEBpYW5hLm9yZw0KQ2M6IGRyYWZ0LXBlcnJhdWx0LWJlaGF2ZS1kZXByZWNhdGUt bmF0LW1pYi12MS5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSUFOQSAjODMwMDA3 XSBQcm90b2NvbCBBY3Rpb246ICdEZXByZWNhdGlvbiBvZiBNSUIgTW9kdWxlIE5BVC1NSUIgKE1h bmFnZWQgT2JqZWN0cyBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3JzIChOQVQpKScgdG8g UHJvcG9zZWQgU3RhbmRhcmQgKGRyYWZ0LXBlcnJhdWx0LWJlaGF2ZS1kZXByZWNhdGUtbmF0LW1p Yi12MS0wNC50eHQpDQoNCkxvb2tzIGdnb29kLCB0aGFuayB5b3UuDQoNClRvbSBUYXlsb3INCg0K T24gMDEvMDcvMjAxNSA3OjI2IFBNLCBBbWFuZGEgQmFiZXIgdmlhIFJUIHdyb3RlOg0KPiBEZWFy IEF1dGhvcnM6DQo+DQo+IEFUVEVOVElPTjogQSBSRVNQT05TRSBUTyBUSElTIE1FU1NBR0UgSVMg TkVFREVEDQo+DQo+IFdlJ3ZlIGNvbXBsZXRlZCB0aGUgSUFOQSBBY3Rpb25zIGZvciB0aGUgZm9s bG93aW5nIFJGQy10by1iZToNCj4NCj4gZHJhZnQtcGVycmF1bHQtYmVoYXZlLWRlcHJlY2F0ZS1u YXQtbWliLXYxLTA0DQo+DQo+IElBTkEgaGFzIHVwZGF0ZWQgdGhlIG1pYi0yIHJlZ2lzdHJhdGlv biBhc3NvY2lhdGVkIHdpdGggdmFsdWUgMTIzIHRvIHJlYWQgYXMgZm9sbG93czoNCj4NCj4gMTIz CW5hdE1JQiAoT0JTT0xFVEUpCU5BVC1NSUIJW1JGQy1wZXJyYXVsdC1iZWhhdmUtZGVwcmVjYXRl LW5hdC1taWItdjEtMDVdDQo+DQo+IFBsZWFzZSBzZWUNCj4gaHR0cDovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy9zbWktbnVtYmVycw0KPg0KPg0KPiBQbGVhc2UgbGV0IHVzIGtub3cgd2hldGhl ciB0aGUgYWJvdmUgSUFOQSBBY3Rpb25zIGxvb2sgT0suIEFzIHNvb24gYXMgd2UgcmVjZWl2ZSB5 b3VyIGNvbmZpcm1hdGlvbiwgd2UnbGwgbm90aWZ5IHRoZSBSRkMgRWRpdG9yIHRoYXQgdGhpcyBk b2N1bWVudCdzIElBTkEgQWN0aW9ucyBhcmUgY29tcGxldGUuIChJZiB0aGlzIGRvY3VtZW50IGhh cyBhIHRlYW0gb2YgYXV0aG9ycywgb25lIHJlcGx5IG9uIGJlaGFsZiBvZiBldmVyeW9uZSB3aWxs IHN1ZmZpY2UuKQ0KPg0KPiBXZSdsbCB1cGRhdGUgdGhlIHJlZmVyZW5jZSB3aGVuIHRoZSBSRkMg RWRpdG9yIG5vdGlmaWVzIHVzIHRoYXQgdGhleSd2ZSBhc3NpZ25lZCBhIG51bWJlci4NCj4NCj4g VGhhbmtzLA0KPg0KPiBBbWFuZGEgQmFiZXINCj4gSUFOQSBTZW5pb3IgU3BlY2lhbGlzdA0KPiBJ Q0FOTg0KPg0KPg0K From nobody Thu Jul 2 15:07:15 2015 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 91C831A8F3C for ; Thu, 2 Jul 2015 15:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 h66bjy-WCcqK; Thu, 2 Jul 2015 15:07:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBADD1A90D8; Thu, 2 Jul 2015 15:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Spencer Dawkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702220632.21084.83937.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 15:06:32 -0700 From: IETF Secretariat Archived-At: Subject: [BEHAVE] ID Tracker State Update Notice: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 22:07:14 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ From nobody Mon Jul 6 10:20:41 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C42411B3263; Fri, 3 Jul 2015 18:30:57 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969F51B3262 for ; Fri, 3 Jul 2015 18:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_NEUTRAL=0.779] 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 UbRQb83StOFe for ; Fri, 3 Jul 2015 18:30:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2509E1AD291 for ; Fri, 3 Jul 2015 18:30:56 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net ([2001:558:fe21:29:69:252:207:42]:36042) by zinfandel.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZBCI3-0002do-02 for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Fri, 03 Jul 2015 18:30:55 -0700 Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-10v.sys.comcast.net with comcast id o1Wh1q00127uzMh011WhwH; Sat, 04 Jul 2015 01:30:41 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by resomta-ch2-02v.sys.comcast.net with comcast id o1Wd1q00D2yZEBF011WeEi; Sat, 04 Jul 2015 01:30:41 +0000 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_809A4400-BEE3-458B-84E3-3CDDFA3F4D61" From: David Harrington In-Reply-To: Date: Fri, 3 Jul 2015 21:30:28 -0400 Message-Id: <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> To: "drafts-approval@iana.org" X-Mailer: Apple Mail (2.1878.6) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1435973441; bh=kg/woFTob0TkGQHMFoPVFCMD0CNWoS/+m1BceoPa5BY=; h=Received:Received:Subject:Mime-Version:Content-Type:From:Date: Message-Id:To; b=mZHRYvspRCunR+R+Bita31B4XImZ+hcL8djH/7mzdBI5oTvvJ+mm81jxEcIhhNvdp sPCi3b5oLmm6B6SaBNJpzzfaI2BUlVyYHB0U+CPZF8rFtWPPBHH+DFX+GvVrxwVZ2F FPACkt2/Cqx03Xl5iN58XDl19nfXw33UOsQXOfZTU16iPLkagFdCPWDuHxdeuBUJZi pKiyeOHopwCJGWFVnm/yT7gY7iWykaHVh65XrTGfC4oHydxMFOogqN55lz5uCwoyuA TqwqiQxJYG8/Be1ZzB4shpuJTLWbeZhVA/NNA5fUHOhzixqp1JAiAV6emE7Y6xROAA Te03EQbziSmDQ== X-SA-Exim-Connect-IP: 2001:558:fe21:29:69:252:207:42 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: ietfdbh@comcast.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150704013056.2509E1AD291@ietfa.amsl.com> Resent-Date: Fri, 3 Jul 2015 18:30:56 -0700 (PDT) Resent-From: ietfdbh@comcast.net Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Jul 2015 10:20:33 -0700 Cc: "draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org" , Tom Taylor Subject: Re: [BEHAVE] [IANA #830007] Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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: Sat, 04 Jul 2015 01:30:57 -0000 --Apple-Mail=_809A4400-BEE3-458B-84E3-3CDDFA3F4D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Amanda,=20 This is not correct. the status for natMIB is DEPRECATED, not OBSOLETE " REVISION "201506240000Z" -- RFC Ed.: set to publication date DESCRIPTION "Deprecation of all objects, published as RFC yyyy. See NAT-MIB-V2 in RFCzzzz for recommended replacement." The format for deprecated assignments is 123 natMIB NAT-MIB (DEPRECATED) = [RFC-perrault-behave-deprecate-nat-mib-v1-05] Here is the entry for {mib-2 68} for an example of another deprecated = MIB module under mib-2. 68 vrrpMIB VRRP MIB (DEPRECATED) [Bob_Hinden][RFC6527] Under ifTypes, there are multiple deprecated assignments (7, 11, 62, 69, = 117, 184, 205, 230) that also follow this format. David Harrington ietfdbh@comcast.net On Jul 1, 2015, at 8:55 PM, Tina TSOU = wrote: > Dear all, >=20 > It looks good to me too. >=20 > Thank you for your great work. >=20 >=20 > Thank you, > Tina >=20 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 > Sent: Thursday, July 02, 2015 10:09 AM > To: drafts-approval@iana.org > Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org > Subject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB = Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' = to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) >=20 > Looks ggood, thank you. >=20 > Tom Taylor >=20 > On 01/07/2015 7:26 PM, Amanda Baber via RT wrote: >> Dear Authors: >>=20 >> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED >>=20 >> We've completed the IANA Actions for the following RFC-to-be: >>=20 >> draft-perrault-behave-deprecate-nat-mib-v1-04 >>=20 >> IANA has updated the mib-2 registration associated with value 123 to = read as follows: >>=20 >> 123 natMIB (OBSOLETE) NAT-MIB = [RFC-perrault-behave-deprecate-nat-mib-v1-05] >>=20 >> Please see >> http://www.iana.org/assignments/smi-numbers >>=20 >>=20 >> Please let us know whether the above IANA Actions look OK. As soon as = we receive your confirmation, we'll notify the RFC Editor that this = document's IANA Actions are complete. (If this document has a team of = authors, one reply on behalf of everyone will suffice.) >>=20 >> We'll update the reference when the RFC Editor notifies us that = they've assigned a number. >>=20 >> Thanks, >>=20 >> Amanda Baber >> IANA Senior Specialist >> ICANN >>=20 >>=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail=_809A4400-BEE3-458B-84E3-3CDDFA3F4D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Amanda, 

This is not = correct.

the status for natMIB is DEPRECATED, not = OBSOLETE

" REVISION "201506240000Z"
   -- RFC Ed.: =
set to publication date
        DESCRIPTION
                "Deprecation of all objects, published as RFC yyyy.
                 See NAT-MIB-V2 in RFCzzzz for recommended =
replacement."

The format for deprecated = assignments is
123 natMIB NAT-MIB = (DEPRECATED) = [RFC-perrault-behave-deprecate-nat-mib-v1-05]

<= div>Here is the entry for  {mib-2 68} for an example of another = deprecated MIB module under mib-2.

Under ifTypes, there are multiple = deprecated assignments (7, 11, 62, 69, 117, 184, 205, 230) that also = follow this format.

David Harrington

=


On Jul 1, 2015, at 8:55 PM, Tina TSOU <Tina.Tsou.Zouting@huawei.com<= /a>> wrote:

Dear all,

It looks good to me too.

Thank you = for your great work.


Thank you,
Tina

-----Original = Message-----
From: Tom Taylor [mailto:tom.taylor.stds@gmail.com= ]
Sent: Thursday, July 02, 2015 10:09 AM
To: drafts-approval@iana.org
C= c: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org
S= ubject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB Module = NAT-MIB (Managed Objects for Network Address Translators (NAT))' to = Proposed Standard = (draft-perrault-behave-deprecate-nat-mib-v1-04.txt)

Looks ggood, = thank you.

Tom Taylor

On 01/07/2015 7:26 PM, Amanda Baber = via RT wrote:
Dear = Authors:

ATTENTION: A RESPONSE TO THIS MESSAGE IS = NEEDED

We've completed the IANA Actions for the following = RFC-to-be:

draft-perrault-behave-deprecate-nat-mib-v1-04

IAN= A has updated the mib-2 registration associated with value 123 to read = as follows:

123 natMIB (OBSOLETE) = NAT-MIB = [RFC-perrault-behave-deprecate-nat-mib-v1-05]

Please = see
http://www.iana.org/a= ssignments/smi-numbers


Please let us know whether the = above IANA Actions look OK. As soon as we receive your confirmation, = we'll notify the RFC Editor that this document's IANA Actions are = complete. (If this document has a team of authors, one reply on behalf = of everyone will suffice.)

We'll update the reference when the = RFC Editor notifies us that they've assigned a = number.

Thanks,

Amanda Baber
IANA Senior = Specialist
ICANN


______________________________= _________________
Behave mailing list
Behave@ietf.org
https://www.ietf.or= g/mailman/listinfo/behave

= --Apple-Mail=_809A4400-BEE3-458B-84E3-3CDDFA3F4D61-- From nobody Mon Jul 6 10:40:16 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A18011B3002; Mon, 6 Jul 2015 10:24:41 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D061B2FFA for ; Mon, 6 Jul 2015 10:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] 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 ETFcYHK3NWjB for ; Mon, 6 Jul 2015 10:24:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471C11B2FE3 for ; Mon, 6 Jul 2015 10:24:40 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:38001 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCA8F-0004Ze-6S for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 06 Jul 2015 10:24:40 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t66HOClX011953 for ; Mon, 6 Jul 2015 17:24:12 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id B7FAAC207BE; Mon, 6 Jul 2015 17:24:12 +0000 (UTC) RT-Owner: Nobody From: "Amanda Baber via RT" In-Reply-To: <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #831872 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 06 Jul 2015 17:24:12 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150706172440.471C11B2FE3@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 10:24:40 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 06 Jul 2015 10:40:13 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval@iana.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:24:41 -0000 Hi David, all, The IANA Considerations section says, "IANA is requested to mark that identifier as OBSOLETE and to update the reference from [RFC4008] to the present document." Should the IANA Considerations section be updated, or should the MIB be updated? thanks, Amanda On Sat Jul 04 01:41:11 2015, ietfdbh@comcast.net wrote: > Hi Amanda, > > This is not correct. > > the status for natMIB is DEPRECATED, not OBSOLETE > > " REVISION "201506240000Z" > -- RFC Ed.: set to publication date > DESCRIPTION > "Deprecation of all objects, published as RFC yyyy. > See NAT-MIB-V2 in RFCzzzz for recommended > replacement." > > The format for deprecated assignments is > 123 natMIB NAT-MIB (DEPRECATED) [RFC-perrault-behave- > deprecate-nat-mib-v1-05] > > Here is the entry for {mib-2 68} for an example of another deprecated > MIB module under mib-2. > 68 vrrpMIB VRRP MIB (DEPRECATED) [Bob_Hinden][RFC6527] > > Under ifTypes, there are multiple deprecated assignments (7, 11, 62, > 69, 117, 184, 205, 230) that also follow this format. > > David Harrington > ietfdbh@comcast.net > > > > On Jul 1, 2015, at 8:55 PM, Tina TSOU > wrote: > > > Dear all, > > > > It looks good to me too. > > > > Thank you for your great work. > > > > > > Thank you, > > Tina > > > > -----Original Message----- > > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > > Sent: Thursday, July 02, 2015 10:09 AM > > To: drafts-approval@iana.org > > Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org > > Subject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB > > Module NAT-MIB (Managed Objects for Network Address Translators > > (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat- > > mib-v1-04.txt) > > > > Looks ggood, thank you. > > > > Tom Taylor > > > > On 01/07/2015 7:26 PM, Amanda Baber via RT wrote: > >> Dear Authors: > >> > >> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > >> > >> We've completed the IANA Actions for the following RFC-to-be: > >> > >> draft-perrault-behave-deprecate-nat-mib-v1-04 > >> > >> IANA has updated the mib-2 registration associated with value 123 to > >> read as follows: > >> > >> 123 natMIB (OBSOLETE) NAT-MIB [RFC-perrault-behave-deprecate- > >> nat-mib-v1-05] > >> > >> Please see > >> http://www.iana.org/assignments/smi-numbers > >> > >> > >> Please let us know whether the above IANA Actions look OK. As soon > >> as we receive your confirmation, we'll notify the RFC Editor that > >> this document's IANA Actions are complete. (If this document has a > >> team of authors, one reply on behalf of everyone will suffice.) > >> > >> We'll update the reference when the RFC Editor notifies us that > >> they've assigned a number. > >> > >> Thanks, > >> > >> Amanda Baber > >> IANA Senior Specialist > >> ICANN > >> > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Jul 6 13:50:40 2015 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 171041B325B for ; Mon, 6 Jul 2015 13:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sTB9UXN32jBx; Mon, 6 Jul 2015 13:50:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5B11B325D; Mon, 6 Jul 2015 13:50:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "Spencer Dawkins" , , "RFC Editor" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706205034.23536.41625.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 13:50:34 -0700 Archived-At: Subject: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:50:38 -0000 A new version (-06) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-06 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. IETF Secretariat. From nobody Mon Jul 6 13:54:17 2015 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 BAD4A1B3223 for ; Mon, 6 Jul 2015 13:54:15 -0700 (PDT) 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 7Mt2WFF55ko4 for ; Mon, 6 Jul 2015 13:54:13 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EB21B3219 for ; Mon, 6 Jul 2015 13:54:13 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so244928858igc.1 for ; Mon, 06 Jul 2015 13:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=5530XENa9PcLdhZbztEW8VX7051lkoZc+3eE9gwAc/s=; b=XdTmjTDYFS562mvYvbj4JJWVEnCLtRqVZUk1zEUchrQrbA84rID1SPqAiOLZCbqExF f2ehtK67P3jG+orIrZXsRgj63XxLFJ+EvWbLgw4rof7lFrADJScta9dE368HSUHpE4Bq ljgSXQXsqsQxZ1PhJn/EzysIil5C6vgYGHTytIMojTVywven17jYd01xa4fTYz6zJpxP 5Xc7WAROVhsrB2Pn4RlQPx30AdWc4tXV982OMctYhUDfWSIgyPaVrMywbxEES49AnaZV 9JaAxzsI8jidIPB2t737kTj2PxJ8Q2gt4e4m/Ar3PHbV4UnacxHoXGo5YshyKTGxUpds QoEg== X-Received: by 10.50.3.6 with SMTP id 6mr49909278igy.28.1436216051715; Mon, 06 Jul 2015 13:54:11 -0700 (PDT) Received: from [192.168.1.135] ([108.63.184.68]) by smtp.gmail.com with ESMTPSA id k16sm10409513igf.19.2015.07.06.13.54.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 13:54:11 -0700 (PDT) To: simon.perreault@jive.com, ssenthil@cisco.com, tina.tsou.zouting@huawei.com, behave@ietf.org, Spencer Dawkins , RFC Editor References: <20150706205034.23536.41625.idtracker@ietfa.amsl.com> From: Tom Taylor Message-ID: <559AEAF1.8070104@gmail.com> Date: Mon, 6 Jul 2015 16:54:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150706205034.23536.41625.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Harrington Subject: Re: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-06.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, 06 Jul 2015 20:54:15 -0000 The only change was from OBSOLETED to DEPRECATED in the IANA section. Tom On 06/07/2015 4:50 PM, internet-drafts@ietf.org wrote: > > A new version (-06) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: > https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-06.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-06 > > 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. > > IETF Secretariat. > > From nobody Mon Jul 6 14:04:24 2015 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 CDEB51B327F for ; Mon, 6 Jul 2015 14:04:23 -0700 (PDT) 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 eO9uB4Tx8Kz5 for ; Mon, 6 Jul 2015 14:04:22 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5072F1B327A for ; Mon, 6 Jul 2015 14:04:22 -0700 (PDT) Received: by igau2 with SMTP id u2so21545826iga.0 for ; Mon, 06 Jul 2015 14:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=EaFCh9BQL0gHqT7zk4jIpOhcWwVudWJuAEAMkVC2dhY=; b=llw5ZzLDERWHlj2Iqop4DSDyUboPVo1oqRu0miT9Ut9burgvqMlmuYCF1PQdo/rjYT 7HfGOSh45Lf7T4gtg8no4X2OimxhJ8aC+83uGhFvYv0xKTRV/UtV7d2aWNMprk1HFDcZ hyJVLACWsNxlHE/2SFZR5sLoJ9PW2LYEy+pBU4aaM+EqpDdoJ5FxtKZaz93MBwkgItEB GN7vW9mXUCcXCKwWhBdFwGtZ7wvK4H2QJ7DmdVeSzGHPRn9Qhz98EwTNbxs8KBF0MWH0 sLBg8vbyPF0dEPBqR/fNe/ryK4BXgsLxAv4OojSWsJp83ZhNM7kpywE2ZtVMs/Aif62+ zXGg== X-Received: by 10.50.142.9 with SMTP id rs9mr43618139igb.17.1436216661817; Mon, 06 Jul 2015 14:04:21 -0700 (PDT) Received: from [192.168.1.135] ([108.63.184.68]) by mx.google.com with ESMTPSA id a82sm13199993ioe.22.2015.07.06.14.04.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 14:04:20 -0700 (PDT) From: Tom Taylor To: Simon Perreault , ssenthil@cisco.com, tina.tsou.zouting@huawei.com, behave@ietf.org, Spencer Dawkins , RFC Editor References: <20150706205034.23536.41625.idtracker@ietfa.amsl.com> Message-ID: <559AED53.8020405@gmail.com> Date: Mon, 6 Jul 2015 17:04:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150706205034.23536.41625.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Harrington Subject: Re: [BEHAVE] New Version Notification - draft-perrault-behave-deprecate-nat-mib-v1-06.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, 06 Jul 2015 21:04:24 -0000 Argh! Messed up Simon's address again. Tom The only change was from OBSOLETED to DEPRECATED in the IANA section. Tom On 06/07/2015 4:50 PM, internet-drafts@ietf.org wrote: > > A new version (-06) has been submitted for draft-perrault-behave-deprecate-nat-mib-v1: > https://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-06.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-06 > > 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. > > IETF Secretariat. > > From nobody Tue Jul 7 08:33:22 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EF3471B30FE; Mon, 6 Jul 2015 12:40:44 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927651B30FD for ; Mon, 6 Jul 2015 12:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] 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 v6xvBWrM4l42 for ; Mon, 6 Jul 2015 12:40:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A731B30FA for ; Mon, 6 Jul 2015 12:40:42 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:44770 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCCFs-0001wZ-06 for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 06 Jul 2015 12:40:41 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t66JeYl5022316 for ; Mon, 6 Jul 2015 19:40:34 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 536CEC207B3; Mon, 6 Jul 2015 19:40:34 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #831872 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 06 Jul 2015 19:40:34 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150706194042.39A731B30FA@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:40:42 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 08:33:21 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval-comment@iana.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:40:45 -0000 Hi, Simon's address is bouncing when I write to the draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org address. thanks, Amanda On Mon Jul 06 19:37:41 2015, iana-shared@icann.org wrote: > > > From: Mail Delivery System DAEMON@ietfa.amsl.com> > Date: Monday, July 6, 2015Anno Domini at 10:24 AM > To: "expand-draft-perrault-behave-deprecate-nat-mib- > v1.all@virtual.ietf.org nat-mib-v1.all@virtual.ietf.org>" deprecate-nat-mib-v1.all@virtual.ietf.org perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org>> > Subject: Undeliverable: [IANA #831872] Re: [BEHAVE] Protocol Action: > 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network > Address Translators (NAT))' to Proposed Standard (draft-perrault- > behave-deprecate-nat-mib-v1-04.txt) > > > Delivery has failed to these recipients or groups: > > expand-draft-perrault-behave-deprecate-nat-mib- > v1.all@virtual.ietf.org nat-mib-v1.all@virtual.ietf.org> > The email address you entered couldn't be found. Please check the > recipient's email address and try to resend the message. If the > problem continues, please contact your helpdesk. > > > The following organization rejected your message: jazz.viagenie.ca. > > > > > > > > Diagnostic information for administrators: > > Generating server: ietfa.amsl.com > > expand-draft-perrault-behave-deprecate-nat-mib- > v1.all@virtual.ietf.org nat-mib-v1.all@virtual.ietf.org> > jazz.viagenie.ca > Remote Server returned ' >: > Recipient address rejected: User unknown in local recipient table>' > > Original message headers: > > Return-Path: > > Received: by ietfa.amsl.com (Postfix, from userid 65534) > id A18011B3002; Mon, 6 Jul 2015 10:24:41 -0700 (PDT) > X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib- > v1.all@ietfa.amsl.com nat-mib-v1.all@ietfa.amsl.com> > Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib- > v1.all@ietfa.amsl.com nat-mib-v1.all@ietfa.amsl.com> > Received: from localhost (ietfa.amsl.com [127.0.0.1]) > by ietfa.amsl.com (Postfix) with ESMTP id 77D061B2FFA > for v1.all@ietfa.amsl.com nat-mib-v1.all@ietfa.amsl.com>>; > Mon, 6 Jul 2015 10:24:41 -0700 (PDT) > X-Virus-Scanned: amavisd-new at amsl.com > X-Spam-Flag: NO > X-Spam-Score: -0.1 > X-Spam-Level: > X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 > tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] > 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 ETFcYHK3NWjB > for v1.all@ietfa.amsl.com nat-mib-v1.all@ietfa.amsl.com>>; > Mon, 6 Jul 2015 10:24:40 -0700 (PDT) > Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org > [IPv6:2001:1890:123a::1:2a]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 > bits)) > (No client certificate requested) > by ietfa.amsl.com (Postfix) with ESMTPS id 471C11B2FE3 > for v1.all@ietf.org v1.all@ietf.org>>; > Mon, 6 Jul 2015 10:24:40 -0700 (PDT) > Received: from smtp01.icann.org ([192.0.33.81]:38001 > helo=smtp1.lax.icann.org) > by zinfandel.tools.ietf.org with esmtps > (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) > (envelope-from >) > id 1ZCA8F-0004Ze-6S > for draft-perrault-behave-deprecate-nat-mib- > v1.all@tools.ietf.org v1.all@tools.ietf.org>; > Mon, 06 Jul 2015 10:24:40 -0700 > Received: from request3.lax.icann.org (request1.lax.icann.org > [10.32.11.221]) > by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t66HOClX011953 > for v1.all@tools.ietf.org v1.all@tools.ietf.org>>; > Mon, 6 Jul 2015 17:24:12 GMT > Received: by request3.lax.icann.org (Postfix, from userid 48) > id B7FAAC207BE; Mon, 6 Jul 2015 17:24:12 +0000 (UTC) > RT-Owner: Nobody > From: Amanda Baber via RT approval@iana.org>> > Reply-To: > > In-Reply-To: <78FF46EF-42AF-4B12-A255- > 931596BDC3F0@comcast.net 931596BDC3F0@comcast.net>> > References: 831872@icann.org>> 830007@icann.org>> > <20150624164600.27690.81498.idtracker@ietfa.amsl.com> > 9660-1435793159-1016.830007-7-0@icann.org>> > <5594810A.1040609@gmail.com> > mbs.china.huawei.com mbs.china.huawei.com>> > <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net 42AF-4B12-A255-931596BDC3F0@comcast.net>> > Message-ID: 0@icann.org> > X-RT-Loop-Prevention: IANA > X-RT-Ticket: IANA #831872 > X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) > X-RT-Originator: amanda.baber@icann.org > CC: v1.all@tools.ietf.org v1.all@tools.ietf.org>> > Content-Type: text/plain; charset="utf-8" > X-RT-Original-Encoding: utf-8 > Precedence: bulk > Date: Mon, 6 Jul 2015 17:24:12 +0000 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-SA-Exim-Connect-IP: 192.0.33.81 > X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib- > v1.all@tools.ietf.org v1.all@tools.ietf.org> > X-SA-Exim-Mail-From: iana-shared@icann.org shared@icann.org> > Subject: [IANA #831872] Re: [BEHAVE] Protocol Action: 'Deprecation of > MIB > Module NAT-MIB (Managed Objects for Network Address Translators > (NAT))' to > Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) > X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) > X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) > Resent-To: v1.all@ietf.org v1.all@ietf.org>> > List-ID: v1.all@tools.ietf.org v1.all@tools.ietf.org>> > Resent-Message-ID: > <20150706172440.471C11B2FE3@ietfa.amsl.com> > Resent-Date: Mon, 6 Jul 2015 10:24:40 -0700 > Resent-From: > > Archived-At: behave-deprecate-nat-mib-v1.all@tools/r0hzmvTDt5eJO6x6K-bvQO1bCfE> > From nobody Tue Jul 7 08:33:24 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BBBA71B31FB; Mon, 6 Jul 2015 13:24:39 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927D81B31FA for ; Mon, 6 Jul 2015 13:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 H8Gj8B0nc_20 for ; Mon, 6 Jul 2015 13:24:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C766C1B31F8 for ; Mon, 6 Jul 2015 13:24:33 -0700 (PDT) Received: from mail-oi0-f41.google.com ([209.85.218.41]:33127) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCCwK-0000RF-HJ for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 06 Jul 2015 13:24:33 -0700 Received: by oiyy130 with SMTP id y130so126568831oiy.0 for ; Mon, 06 Jul 2015 13:24:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r135yMrf5gH7a/kGFkCe0CJvSapmfBYoQEWABUhs2JM=; b=KageS33DZmBM8Z8NbrB7vUOp8mvWv/TN1cS2gRbEaDcb2aw2P1/CoKjgB4kFWnKdgw Bxc84/OuB8amIxfZdWcwRxrqh2Q+c3CWToyH9hA2uOOaoeEQM34KOKLt+ZxORXZpyTJt j0+dk6eGDUrgiPz2GYT8/pTQJPzFY18RBoowMZW8g3InOB4pnvOrF1GfEHN5C6P/kNCz eyb7iBudq5IkJa7z0QtU4ZJe39eDTPnEmEvE+WQ7ZYGQjyH2QuUQKTu02gl2/m9YRkuR vkPxIidbChA3Lp0jBzVLRV9nvZKMxxNQOIXhNo4JlxCHMm4vU2MlhFXyrPadSvcuikKe hAXg== X-Gm-Message-State: ALoCoQkQXfhNrmiT+AU0slyL0L98itwgNVTHK7jAJUfYULkd4oKue0R/oRKIxbzChH0mp30+6zfX X-Received: by 10.60.177.73 with SMTP id co9mr589281oec.5.1436214265598; Mon, 06 Jul 2015 13:24:25 -0700 (PDT) Received: from [192.168.1.44] ([24.53.47.130]) by mx.google.com with ESMTPSA id c5sm10560620oel.12.2015.07.06.13.24.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 13:24:24 -0700 (PDT) Message-ID: <559AE3F6.90109@jive.com> Date: Mon, 06 Jul 2015 16:24:22 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: drafts-approval-comment@iana.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 209.85.218.41 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: sperreault@jive.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150706202433.C766C1B31F8@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 13:24:33 -0700 (PDT) Resent-From: sperreault@jive.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 08:33:21 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: Re: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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, 06 Jul 2015 20:24:39 -0000 Le 2015-07-06 15:40, Amanda Baber via RT a écrit : > Simon's address is bouncing when I write to the draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org address. My contact info in the draft should be updated to: Simon Perreault Jive Communications Québec, QC Canada E-mail: sperreault@jive.com Simon From nobody Tue Jul 7 08:33:25 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9BBE71B31CF; Mon, 6 Jul 2015 13:25:04 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672801B31DF for ; Mon, 6 Jul 2015 13:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 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_SOFTFAIL=0.665] 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 pvdGoKUan2iR for ; Mon, 6 Jul 2015 13:25:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6F81B31CF for ; Mon, 6 Jul 2015 13:25:02 -0700 (PDT) Received: from mail-ie0-x22c.google.com ([2607:f8b0:4001:c03::22c]:34906) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCCwn-0007wB-88 for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 06 Jul 2015 13:25:02 -0700 Received: by iecuq6 with SMTP id uq6so121122823iec.2 for ; Mon, 06 Jul 2015 13:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=bzNff8T+okOEg1iNwnTrHTMkbJOER1LCmvAsKVg4qaQ=; b=UfNl5vIxx34N8XSozVc7TwUi9dSGPWmtAgUVDr4OjiWipuivVNWzoPVG9h/rjER5Ud ufjAfZl0G0jf9NjTKXCOEQvYlQ6L3DGxC8xRahbDAWt4nG+J6PnvpfViyczaiSgQMKEN vFgy5I8YWV9OdYcDAHQMLlWEK2+zqgcZn9ieq9qXEGX2Ltv3AdzWSICxRJ0cTnaQ83UX PSWtcxWLmKAfXWdy8LbCyjk36wWmMBVcDrvcaoeJe6jPvEvA6cUL7Nf8E+5gEaSqh1bN fc/sXrmWgWcX42UEw2F0qlmzwkNE3eUFAT4yPAZzBHetFE/o/bR4yrek16UNxesDYLjw k7yg== X-Received: by 10.107.150.14 with SMTP id y14mr1040127iod.55.1436214294144; Mon, 06 Jul 2015 13:24:54 -0700 (PDT) Received: from [192.168.1.135] ([108.63.184.68]) by mx.google.com with ESMTPSA id d4sm13135671iod.17.2015.07.06.13.24.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 13:24:53 -0700 (PDT) To: drafts-approval@iana.org References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> From: Tom Taylor Message-ID: <559AE414.2050001@gmail.com> Date: Mon, 6 Jul 2015 16:24:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2607:f8b0:4001:c03::22c X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: tom.taylor.stds@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150706202502.2C6F81B31CF@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 13:25:02 -0700 (PDT) Resent-From: tom.taylor.stds@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 08:33:21 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: Re: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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, 06 Jul 2015 20:25:04 -0000 I'd go with David as expert: the IANA Considerations section should be updated. Tom On 06/07/2015 1:24 PM, Amanda Baber via RT wrote: > Hi David, all, > > The IANA Considerations section says, "IANA is requested to mark that identifier as OBSOLETE and to update the reference from [RFC4008] to the present document." > > Should the IANA Considerations section be updated, or should the MIB be updated? > > thanks, > Amanda > > > > On Sat Jul 04 01:41:11 2015, ietfdbh@comcast.net wrote: >> Hi Amanda, >> >> This is not correct. >> >> the status for natMIB is DEPRECATED, not OBSOLETE >> >> " REVISION "201506240000Z" >> -- RFC Ed.: set to publication date >> DESCRIPTION >> "Deprecation of all objects, published as RFC yyyy. >> See NAT-MIB-V2 in RFCzzzz for recommended >> replacement." >> >> The format for deprecated assignments is >> 123 natMIB NAT-MIB (DEPRECATED) [RFC-perrault-behave- >> deprecate-nat-mib-v1-05] >> >> Here is the entry for {mib-2 68} for an example of another deprecated >> MIB module under mib-2. >> 68 vrrpMIB VRRP MIB (DEPRECATED) [Bob_Hinden][RFC6527] >> >> Under ifTypes, there are multiple deprecated assignments (7, 11, 62, >> 69, 117, 184, 205, 230) that also follow this format. >> >> David Harrington >> ietfdbh@comcast.net >> >> >> >> On Jul 1, 2015, at 8:55 PM, Tina TSOU >> wrote: >> >>> Dear all, >>> >>> It looks good to me too. >>> >>> Thank you for your great work. >>> >>> >>> Thank you, >>> Tina >>> >>> -----Original Message----- >>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>> Sent: Thursday, July 02, 2015 10:09 AM >>> To: drafts-approval@iana.org >>> Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org >>> Subject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB >>> Module NAT-MIB (Managed Objects for Network Address Translators >>> (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat- >>> mib-v1-04.txt) >>> >>> Looks ggood, thank you. >>> >>> Tom Taylor >>> >>> On 01/07/2015 7:26 PM, Amanda Baber via RT wrote: >>>> Dear Authors: >>>> >>>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED >>>> >>>> We've completed the IANA Actions for the following RFC-to-be: >>>> >>>> draft-perrault-behave-deprecate-nat-mib-v1-04 >>>> >>>> IANA has updated the mib-2 registration associated with value 123 to >>>> read as follows: >>>> >>>> 123 natMIB (OBSOLETE) NAT-MIB [RFC-perrault-behave-deprecate- >>>> nat-mib-v1-05] >>>> >>>> Please see >>>> http://www.iana.org/assignments/smi-numbers >>>> >>>> >>>> Please let us know whether the above IANA Actions look OK. As soon >>>> as we receive your confirmation, we'll notify the RFC Editor that >>>> this document's IANA Actions are complete. (If this document has a >>>> team of authors, one reply on behalf of everyone will suffice.) >>>> >>>> We'll update the reference when the RFC Editor notifies us that >>>> they've assigned a number. >>>> >>>> Thanks, >>>> >>>> Amanda Baber >>>> IANA Senior Specialist >>>> ICANN >>>> >>>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave > > > > From nobody Wed Jul 8 08:15:24 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 836AE1A90B6; Tue, 7 Jul 2015 13:41:09 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC41A90A6 for ; Tue, 7 Jul 2015 13:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] 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 TGFxsmuCrHt3 for ; Tue, 7 Jul 2015 13:41:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95151A903E for ; Tue, 7 Jul 2015 13:41:00 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:42517 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCZfm-0003ck-R6 for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Tue, 07 Jul 2015 13:41:00 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t67KeR8s005824; Tue, 7 Jul 2015 20:40:27 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 65737C207B9; Tue, 7 Jul 2015 20:40:27 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> <559AE414.2050001@gmail.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #831872 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 07 Jul 2015 20:40:27 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150707204100.C95151A903E@ietfa.amsl.com> Resent-Date: Tue, 7 Jul 2015 13:41:00 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 08:15:19 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org, ietfdbh@comcast.net Subject: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-04.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval-comment@iana.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 20:41:09 -0000 Hi all, Can one of you confirm that this is correct? 123 natMIB NAT-MIB (DEPRECATED) [RFC-perrault-behave-deprecate-nat-mib-v1-05] See http://www.iana.org/assignments/smi-numbers If so, I'll send the RFC Editor a note about the change. thanks, Amanda On Mon Jul 06 20:25:15 2015, tom.taylor.stds@gmail.com wrote: > I'd go with David as expert: the IANA Considerations section should be > updated. > > Tom > > On 06/07/2015 1:24 PM, Amanda Baber via RT wrote: > > Hi David, all, > > > > The IANA Considerations section says, "IANA is requested to mark that > > identifier as OBSOLETE and to update the reference from [RFC4008] to > > the present document." > > > > Should the IANA Considerations section be updated, or should the MIB > > be updated? > > > > thanks, > > Amanda > > > > > > > > On Sat Jul 04 01:41:11 2015, ietfdbh@comcast.net wrote: > >> Hi Amanda, > >> > >> This is not correct. > >> > >> the status for natMIB is DEPRECATED, not OBSOLETE > >> > >> " REVISION "201506240000Z" > >> -- RFC Ed.: set to publication date > >> DESCRIPTION > >> "Deprecation of all objects, published as RFC yyyy. > >> See NAT-MIB-V2 in RFCzzzz for recommended > >> replacement." > >> > >> The format for deprecated assignments is > >> 123 natMIB NAT-MIB (DEPRECATED) [RFC-perrault-behave- > >> deprecate-nat-mib-v1-05] > >> > >> Here is the entry for {mib-2 68} for an example of another > >> deprecated > >> MIB module under mib-2. > >> 68 vrrpMIB VRRP MIB (DEPRECATED) [Bob_Hinden][RFC6527] > >> > >> Under ifTypes, there are multiple deprecated assignments (7, 11, 62, > >> 69, 117, 184, 205, 230) that also follow this format. > >> > >> David Harrington > >> ietfdbh@comcast.net > >> > >> > >> > >> On Jul 1, 2015, at 8:55 PM, Tina TSOU > >> wrote: > >> > >>> Dear all, > >>> > >>> It looks good to me too. > >>> > >>> Thank you for your great work. > >>> > >>> > >>> Thank you, > >>> Tina > >>> > >>> -----Original Message----- > >>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > >>> Sent: Thursday, July 02, 2015 10:09 AM > >>> To: drafts-approval@iana.org > >>> Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org > >>> Subject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB > >>> Module NAT-MIB (Managed Objects for Network Address Translators > >>> (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat- > >>> mib-v1-04.txt) > >>> > >>> Looks ggood, thank you. > >>> > >>> Tom Taylor > >>> > >>> On 01/07/2015 7:26 PM, Amanda Baber via RT wrote: > >>>> Dear Authors: > >>>> > >>>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > >>>> > >>>> We've completed the IANA Actions for the following RFC-to-be: > >>>> > >>>> draft-perrault-behave-deprecate-nat-mib-v1-04 > >>>> > >>>> IANA has updated the mib-2 registration associated with value 123 > >>>> to > >>>> read as follows: > >>>> > >>>> 123 natMIB (OBSOLETE) NAT-MIB [RFC-perrault-behave- > >>>> deprecate- > >>>> nat-mib-v1-05] > >>>> > >>>> Please see > >>>> http://www.iana.org/assignments/smi-numbers > >>>> > >>>> > >>>> Please let us know whether the above IANA Actions look OK. As soon > >>>> as we receive your confirmation, we'll notify the RFC Editor that > >>>> this document's IANA Actions are complete. (If this document has a > >>>> team of authors, one reply on behalf of everyone will suffice.) > >>>> > >>>> We'll update the reference when the RFC Editor notifies us that > >>>> they've assigned a number. > >>>> > >>>> Thanks, > >>>> > >>>> Amanda Baber > >>>> IANA Senior Specialist > >>>> ICANN > >>>> > >>>> > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www.ietf.org/mailman/listinfo/behave > > > > > > > > From nobody Mon Jul 13 08:41:03 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 925C81B2A35; Mon, 13 Jul 2015 05:38:24 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF041B2A33 for ; Mon, 13 Jul 2015 05:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 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_NEUTRAL=0.779] 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 X761osvhr4LF for ; Mon, 13 Jul 2015 05:38:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E741B2A34 for ; Mon, 13 Jul 2015 05:38:23 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net ([2001:558:fe21:29:69:252:207:43]:56389) by zinfandel.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZEd01-000463-82 for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 13 Jul 2015 05:38:22 -0700 Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with comcast id rodR1q0062XD5SV01oeH4b; Mon, 13 Jul 2015 12:38:17 +0000 Received: from [192.168.0.13] ([68.14.87.79]) by resomta-ch2-20v.sys.comcast.net with comcast id roe41q0071iiXV801oe6p8; Mon, 13 Jul 2015 12:38:15 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Harrington In-Reply-To: <559AE414.2050001@gmail.com> Date: Mon, 13 Jul 2015 08:38:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <373F7664-3D2B-4BE3-9307-6D3D4E19C6CB@comcast.net> References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> <559AE414.2050001@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1878.6) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436791097; bh=Cw/Nj68KxokhLCXVH6xZ60X9rL6ig9Y9oprDcvPPQcU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=pknO5n9GaDSlSLC1HBc8sZWBmz+FdNERJMqjPixrz3lwkr6WR2C1PYbQv2/7KYPOZ ltP0O8nwL1Cqjjl2gW9MkDFZt64AU6r3rkxuK5Ahj8oXTtU+fvhBX1WxCbHAE9GjEi soQ+8tJwWVH2i7NNRQ2QHpxtREd7TR9GrREjAwpDOmVn90v2Zt5sz72GOQNZHCfSsn vuvOomCYeZo2jrWrP2+JVOqlwNoZNVAWlj9WITb4v/DavrTNUu2wX3A4wf2nKLP7CS pzLfOGcOeLKXkN+fF2ZkRj8CRr5dni3D3nCCnEfYK4n2Al7qPCPYc3byMeEXF4osap qG0DucnopjsXw== X-SA-Exim-Connect-IP: 2001:558:fe21:29:69:252:207:43 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: ietfdbh@comcast.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150713123823.14E741B2A34@ietfa.amsl.com> Resent-Date: Mon, 13 Jul 2015 05:38:23 -0700 (PDT) Resent-From: ietfdbh@comcast.net Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 08:41:02 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org, drafts-approval@iana.org Subject: Re: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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, 13 Jul 2015 12:38:24 -0000 Hi, I believe the IANA Considerations should be updated to reflect the = deprecation intent. David Harrington ietfdbh@comcast.net On Jul 6, 2015, at 4:24 PM, Tom Taylor = wrote: > I'd go with David as expert: the IANA Considerations section should be = updated. >=20 > Tom >=20 > On 06/07/2015 1:24 PM, Amanda Baber via RT wrote: >> Hi David, all, >>=20 >> The IANA Considerations section says, "IANA is requested to mark that = identifier as OBSOLETE and to update the reference from [RFC4008] to the = present document." >>=20 >> Should the IANA Considerations section be updated, or should the MIB = be updated? >>=20 >> thanks, >> Amanda >>=20 >>=20 >>=20 >> On Sat Jul 04 01:41:11 2015, ietfdbh@comcast.net wrote: >>> Hi Amanda, >>>=20 >>> This is not correct. >>>=20 >>> the status for natMIB is DEPRECATED, not OBSOLETE >>>=20 >>> " REVISION "201506240000Z" >>> -- RFC Ed.: set to publication date >>> DESCRIPTION >>> "Deprecation of all objects, published as RFC yyyy. >>> See NAT-MIB-V2 in RFCzzzz for recommended >>> replacement." >>>=20 >>> The format for deprecated assignments is >>> 123 natMIB NAT-MIB (DEPRECATED) [RFC-perrault-behave- >>> deprecate-nat-mib-v1-05] >>>=20 >>> Here is the entry for {mib-2 68} for an example of another = deprecated >>> MIB module under mib-2. >>> 68 vrrpMIB VRRP MIB (DEPRECATED) [Bob_Hinden][RFC6527] >>>=20 >>> Under ifTypes, there are multiple deprecated assignments (7, 11, 62, >>> 69, 117, 184, 205, 230) that also follow this format. >>>=20 >>> David Harrington >>> ietfdbh@comcast.net >>>=20 >>>=20 >>>=20 >>> On Jul 1, 2015, at 8:55 PM, Tina TSOU >>> wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> It looks good to me too. >>>>=20 >>>> Thank you for your great work. >>>>=20 >>>>=20 >>>> Thank you, >>>> Tina >>>>=20 >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>>> Sent: Thursday, July 02, 2015 10:09 AM >>>> To: drafts-approval@iana.org >>>> Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org >>>> Subject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB >>>> Module NAT-MIB (Managed Objects for Network Address Translators >>>> (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat- >>>> mib-v1-04.txt) >>>>=20 >>>> Looks ggood, thank you. >>>>=20 >>>> Tom Taylor >>>>=20 >>>> On 01/07/2015 7:26 PM, Amanda Baber via RT wrote: >>>>> Dear Authors: >>>>>=20 >>>>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED >>>>>=20 >>>>> We've completed the IANA Actions for the following RFC-to-be: >>>>>=20 >>>>> draft-perrault-behave-deprecate-nat-mib-v1-04 >>>>>=20 >>>>> IANA has updated the mib-2 registration associated with value 123 = to >>>>> read as follows: >>>>>=20 >>>>> 123 natMIB (OBSOLETE) NAT-MIB = [RFC-perrault-behave-deprecate- >>>>> nat-mib-v1-05] >>>>>=20 >>>>> Please see >>>>> http://www.iana.org/assignments/smi-numbers >>>>>=20 >>>>>=20 >>>>> Please let us know whether the above IANA Actions look OK. As soon >>>>> as we receive your confirmation, we'll notify the RFC Editor that >>>>> this document's IANA Actions are complete. (If this document has a >>>>> team of authors, one reply on behalf of everyone will suffice.) >>>>>=20 >>>>> We'll update the reference when the RFC Editor notifies us that >>>>> they've assigned a number. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Amanda Baber >>>>> IANA Senior Specialist >>>>> ICANN >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Mon Jul 13 08:41:04 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 52FC71B2A46; Mon, 13 Jul 2015 05:46:39 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386921B2A45 for ; Mon, 13 Jul 2015 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_NEUTRAL=0.779] 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 JdNfWqn1wThH for ; Mon, 13 Jul 2015 05:46:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758931B2A37 for ; Mon, 13 Jul 2015 05:46:38 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net ([2001:558:fe21:29:69:252:207:44]:48329) by zinfandel.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZEd81-0007RY-PD for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 13 Jul 2015 05:46:38 -0700 Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-12v.sys.comcast.net with comcast id rolk1q0072GyhjZ01omck2; Mon, 13 Jul 2015 12:46:36 +0000 Received: from [192.168.0.13] ([68.14.87.79]) by resomta-ch2-09v.sys.comcast.net with comcast id romP1q00K1iiXV801omSx4; Mon, 13 Jul 2015 12:46:34 +0000 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_3097099D-5540-47DA-A10D-A49B3900AEBD" From: David Harrington In-Reply-To: Date: Mon, 13 Jul 2015 08:46:23 -0400 Message-Id: <09FE4BC2-4872-4FFF-8811-5334498D0E5B@comcast.net> References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> <559AE414.2050001@gmail.com> To: drafts-approval-comment@iana.org X-Mailer: Apple Mail (2.1878.6) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436791596; bh=5TMD4WAe4lygaHNVg/LpeS9lKCbzTGBT9R5JC/HHWP4=; h=Received:Received:Subject:Mime-Version:Content-Type:From:Date: Message-Id:To; b=aTJ142LrRBVaJv5jVma9sNgVbR1VrZ/ZEaNpJ/9gGZuqcbs/K9X6dtuuwfJc8xVgW eqcfTd0jk9z4Sm41idClXsod0ETMrhiiSAV4Ivof7R3TlEj1kGANHnahZ1Y+vZyfb7 Hu2iqFjPsrnFdyUXlj9zdBlf+Lnwi6pXz6ysMUWCs/HyaqXBmvhDjk7mxws2UuQr9F oL2CW2nVEtJLLbufOZQo8SoB7dIXgp/q7D/sI3Me2+TwBt9+ERd9yxUaBIc6wetVS7 f9o37FGW2kMil+kAbjDpeSQ9b7YlS4wLGx2MpTEOCsXc0lvqlzLkhq9XBC/NcBi9jg N/HsnZv9FfR5w== X-SA-Exim-Connect-IP: 2001:558:fe21:29:69:252:207:44 X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: ietfdbh@comcast.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150713124638.758931B2A37@ietfa.amsl.com> Resent-Date: Mon, 13 Jul 2015 05:46:38 -0700 (PDT) Resent-From: ietfdbh@comcast.net Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 08:41:02 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org Subject: Re: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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, 13 Jul 2015 12:46:39 -0000 --Apple-Mail=_3097099D-5540-47DA-A10D-A49B3900AEBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii correct David Harrington ietfdbh@comcast.net On Jul 7, 2015, at 4:40 PM, Amanda Baber via RT = wrote: >>>>>=20 >>>>> To: drafts-approval@iana.org >>>>> Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org >>>>> Subject: Re: [IANA #830007] Protocol Action: 'Deprecation of MIB >>>>> Module NAT-MIB (Managed Objects for Network Address Translators >>>>> (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat- >>>>> mib-v1-04.txt) --Apple-Mail=_3097099D-5540-47DA-A10D-A49B3900AEBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii correct

David Harrington

=


On Jul 7, 2015, at 4:40 PM, Amanda Baber via RT <drafts-approval-comment@i= ana.org> wrote:


To: drafts-approval@iana.org
C= c: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org
S= ubject: Re: [IANA #830007] Protocol Action: 'Deprecation of = MIB
Module NAT-MIB (Managed Objects for Network Address = Translators
(NAT))' to Proposed Standard = (draft-perrault-behave-deprecate-nat-
mib-v1-04.txt)

<= /html>= --Apple-Mail=_3097099D-5540-47DA-A10D-A49B3900AEBD-- From nobody Mon Jul 13 08:41:06 2015 Return-Path: X-Original-To: expand-draft-perrault-behave-deprecate-nat-mib-v1.all@virtual.ietf.org Delivered-To: behave@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DC14D1B2BBD; Mon, 13 Jul 2015 08:27:52 -0700 (PDT) X-Original-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Delivered-To: xfilter-draft-perrault-behave-deprecate-nat-mib-v1.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFCE1B2BBB for ; Mon, 13 Jul 2015 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 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_SOFTFAIL=0.665] 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 Ri0azGP_Jc-t for ; Mon, 13 Jul 2015 08:27:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28A81B2B7C for ; Mon, 13 Jul 2015 08:27:51 -0700 (PDT) Received: from mail-ig0-x22c.google.com ([2607:f8b0:4001:c05::22c]:36030) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZEfe3-0004uh-6R for draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org; Mon, 13 Jul 2015 08:27:51 -0700 Received: by igbij6 with SMTP id ij6so24363117igb.1 for ; Mon, 13 Jul 2015 08:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=lC6agbd6q2NwkkQKJUlbZCS2TvuVL7dTQ3QT79CCUyI=; b=pplKkldH8pE+qGRK+wozBUYtQy3bk27lRcZiK3I8pXWa9KV2/8W5G9U2cfhVIUuMxa VypPAyfl0rQGr3y+Q9ODaxVsRYW5PZNidSDnHil7KQtqFlosMJwcEUORmCvdw85UKeL7 Dyk+71/QkZ9jVsg5FM/WfrjfovetV7TV82uL9bQnmCALlMnrYvQ5Vi4Kr9IrBo+94Ae0 lmxgge+y9Zb1qU6hB3Al3LXS+Vamu6DtQdChk/f7yyze39JFbntDdUVijnMkPuCLGDbh G+AUniTJIb4wF2A+DsVX42k+KT7K82YSAnmrkHhiXUW+PlvQBebVGxKpJbOsrjqwMCDv jLAg== X-Received: by 10.50.49.46 with SMTP id r14mr13589947ign.45.1436801263359; Mon, 13 Jul 2015 08:27:43 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-74-97.tor.primus.ca. [173.206.74.97]) by smtp.gmail.com with ESMTPSA id rj5sm5899663igc.2.2015.07.13.08.27.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2015 08:27:42 -0700 (PDT) To: David Harrington References: <20150624164600.27690.81498.idtracker@ietfa.amsl.com> <5594810A.1040609@gmail.com> <78FF46EF-42AF-4B12-A255-931596BDC3F0@comcast.net> <559AE414.2050001@gmail.com> <373F7664-3D2B-4BE3-9307-6D3D4E19C6CB@comcast.net> From: Tom Taylor Message-ID: <55A3D8ED.7080208@gmail.com> Date: Mon, 13 Jul 2015 11:27:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <373F7664-3D2B-4BE3-9307-6D3D4E19C6CB@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::22c X-SA-Exim-Rcpt-To: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org X-SA-Exim-Mail-From: tom.taylor.stds@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-perrault-behave-deprecate-nat-mib-v1.all@ietf.org Resent-Message-Id: <20150713152751.E28A81B2B7C@ietfa.amsl.com> Resent-Date: Mon, 13 Jul 2015 08:27:51 -0700 (PDT) Resent-From: tom.taylor.stds@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 08:41:02 -0700 Cc: draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org, drafts-approval@iana.org Subject: Re: [BEHAVE] [IANA #831872] Re: Protocol Action: 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))' to Proposed Standard (draft-perrault-behave-deprecate-nat-mib-v1-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, 13 Jul 2015 15:27:53 -0000 Done in version -06. Tom On 13/07/2015 8:38 AM, David Harrington wrote: > Hi, > > I believe the IANA Considerations should be updated to reflect the deprecation intent. > > David Harrington > ietfdbh@comcast.net > > > > On Jul 6, 2015, at 4:24 PM, Tom Taylor wrote: > >> I'd go with David as expert: the IANA Considerations section should be updated. >> >> Tom >> >> On 06/07/2015 1:24 PM, Amanda Baber via RT wrote: >>> Hi David, all, >>> >>> The IANA Considerations section says, "IANA is requested to mark that identifier as OBSOLETE and to update the reference from [RFC4008] to the present document." >>> >>> Should the IANA Considerations section be updated, or should the MIB be updated? >>> >>> thanks, >>> Amanda >>> >>> ... From nobody Thu Jul 30 14:08:00 2015 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 573321A90A5; Thu, 30 Jul 2015 14:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 37g7OXSTWeQt; Thu, 30 Jul 2015 14:07:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 02F5C1AC3BB; Thu, 30 Jul 2015 14:07:27 -0700 (PDT) Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t6UL7N5I010514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jul 2015 14:07:23 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <20150730205806.GI1667@cisco.com> Date: Thu, 30 Jul 2015 14:07:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> References: <20150730205806.GI1667@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 21:07:57 -0000 > On Jul 30, 2015, at 13:58 , Toerless Eckert wrote: >=20 > For autonomic networking (ANIMA WG), we are planning to rely only on = IPv6 for initial > autonomic connectivity, and the question of connecting this (at least = initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport = seems to be still > weak on a range of commonly used NOC tools. >=20 > If i understand the NAT RFCs and behave output correctly, we = primaerily > want ALGs to go the way of the dodo, so i was wondering if there might = be > any crucial protocols between typical NOC equipment and network = devices that > would require ALGs. And better of course:knowing which protocols would = be fine > without ALG. >=20 > Are there any lists about this (eg: what requires ALG ?) >=20 > Wrt to what seems to be important between NOC and network devices: >=20 > FTP - NOK (requires ALG) - IMHO not a problem FTP should be long deprecated for the most part anyway, however, PASV mode FTP (if you must use FTP) should be OK without need of an ALG. > traceroute - ?? (initiated from v4 NOC) ?? > telnet - OK=20 > ping - OK ? Should generally be OK. Requests must come from translated side of the host pair. Responses can come from either side, but to be = meaningful, need to be responding from native side to translated side. > SSH/SCP - OK > syslog - OK > TFTP - OK ? Should be OK, depending on which side is client. (client has to be the private address/translated side of the connection). > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? Should be OK, again, assuming favorable directionality. If RADIUS/TACACS server is on translated side and router is on native = side, then this will not work without an ALG or some other hackery. > NTP - OK ??? Same directionality considerations apply here. > For the following, that have extensible data-models (MIBs/OIDs, XML = schema etc.), > i can see that some NOC tools relying on them might not support = data-models > with IPv6, but that would be "fine" (aka: can't manage everything = from such tools, > but transport stack works): >=20 > netconf - OK ? > SNMP - OK ? Should be OK, assuming favorable directionality. HTTP HTTPs SMTP IMAP sFlow/cFlow/etc. Owen From nobody Thu Jul 30 14:25:53 2015 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 B38111ACD83; Thu, 30 Jul 2015 14:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 GqoqHQeQKH3a; Thu, 30 Jul 2015 14:25:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FAF1ACD36; Thu, 30 Jul 2015 14:25:51 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6ULOUeR024306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2015 14:24:31 -0700 (PDT) To: Owen DeLong , Toerless Eckert References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55BA960E.7010700@isi.edu> Date: Thu, 30 Jul 2015 14:24:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org, behave@ietf.org, touch@isi.edu Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 21:25:52 -0000 On 7/30/2015 2:07 PM, Owen DeLong wrote: > >> On Jul 30, 2015, at 13:58 , Toerless Eckert wrote: >> >> For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 for initial >> autonomic connectivity, and the question of connecting this (at least initially) >> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems to be still >> weak on a range of commonly used NOC tools. >> >> If i understand the NAT RFCs and behave output correctly, we primaerily >> want ALGs to go the way of the dodo, NATs too, if we're taking requests... ... >> Wrt to what seems to be important between NOC and network devices: >> >> FTP - NOK (requires ALG) - IMHO not a problem > > FTP should be long deprecated for the most part anyway, however, PASV > mode FTP (if you must use FTP) should be OK without need of an ALG. FTP has security problems but anonymous mode access to files is still used. As noted, PASV avoids the need for ALG in-band address translation. All the listed protocols should be OK if the client is behind the NAT (as noted) *or* if the NAT is configured to forward those services to a particular private-side host. Other ALG protocols not on your list: web: HTTP (mostly to hijack initial login screens, somtimes to insert tracking or ads) teleconferencing/media: Apple iChat H.323 MGCP (media gateway) RTSP (realtime streaming) SCCP (Cisco call signalling) SIP remote functions: RPC (Sun, Microsoft) SQL tunneling: PPTP --- From nobody Thu Jul 30 22:11:22 2015 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 BBB0D1B30EA; Thu, 30 Jul 2015 22:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6QG4UCWv-zHB; Thu, 30 Jul 2015 22:11:17 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59961B30E6; Thu, 30 Jul 2015 22:11:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AF1B5A1; Fri, 31 Jul 2015 07:11:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1438319474; bh=kxHgYbmG2zuSoEQHDWzpmu/n2Vs/GeWjDM3rgXUCVjU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TqlkcY4yH2AuY4xSIs9N6G5qqHAlV7fsNoHjfhoCzbkVsjB62Yh8DDNT+702Nh9FM vx5J1NPu6Iy/HHGaPfAQptTNav243Uqkna1YzJTAtJLV6egkmUOZh9T4yMf/Kls5dX 6zhbqcT9sb/rwNtIMs0vDNRmXbFkR8us1y8lx4Go= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A64D89F; Fri, 31 Jul 2015 07:11:14 +0200 (CEST) Date: Fri, 31 Jul 2015 07:11:14 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Message-ID: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Toerless Eckert , behave@ietf.org, v6ops@ietf.org Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:11:18 -0000 On Thu, 30 Jul 2015, Owen DeLong wrote: >> SSH/SCP - OK >> syslog - OK >> TFTP - OK ? > > Should be OK, depending on which side is client. (client has to be the > private address/translated side of the connection). There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 30 22:39:05 2015 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 E66A11B3109; Thu, 30 Jul 2015 22:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9Ats7XSVnR8W; Thu, 30 Jul 2015 22:39:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 49F501B30FF; Thu, 30 Jul 2015 22:39:02 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t6V5cvBe014853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jul 2015 22:38:57 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Thu, 30 Jul 2015 22:38:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55A144E0-74BE-4A29-9A5F-782D7D660399@delong.com> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Toerless Eckert , behave@ietf.org, v6ops@ietf.org Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:39:03 -0000 > On Jul 30, 2015, at 22:11 , Mikael Abrahamsson = wrote: >=20 > On Thu, 30 Jul 2015, Owen DeLong wrote: >=20 >>> SSH/SCP - OK >>> syslog - OK >>> TFTP - OK ? >>=20 >> Should be OK, depending on which side is client. (client has to be = the >> private address/translated side of the connection). >=20 > There are ALGs for TFTP from multiple vendors, and I seem to remember = I had problem performing TFTP download from behind a NAT, but I could be = mistaken. This should be investigated further. You might need STUN or something like that, but you shouldn=E2=80=99t = need an ALG. Owen From nobody Thu Jul 30 22:42:37 2015 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 7F6181B3108; Thu, 30 Jul 2015 22:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GV9U_U6w1g_B; Thu, 30 Jul 2015 22:42:33 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0A31A0354; Thu, 30 Jul 2015 22:42:33 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6B1AA1; Fri, 31 Jul 2015 07:42:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1438321351; bh=N3VN8oOHYtep4435pX0j2Nz85ZNq9YZLIuVPRtbgMT4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ogUIrf6MZtyH5F7uBg0fzqDEcKnpc1phwBrWOy97rTPZUVJNkPvHCc03OuNcnHIZ7 zJ3hhM1wLCx0aozhiyhQ4yp+c84ekX7g9gBJPzoWMO01ik3r2wv+kSt59dJG857lTJ 7EkcMIYhEJvFLnpTdgRshYq/B5NC8ZFBLmtwMEtk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD8849F; Fri, 31 Jul 2015 07:42:31 +0200 (CEST) Date: Fri, 31 Jul 2015 07:42:31 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: <55A144E0-74BE-4A29-9A5F-782D7D660399@delong.com> Message-ID: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <55A144E0-74BE-4A29-9A5F-782D7D660399@delong.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-2013288220-1438321351=:11810" Archived-At: Cc: Toerless Eckert , behave@ietf.org, v6ops@ietf.org Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:42:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-2013288220-1438321351=:11810 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 30 Jul 2015, Owen DeLong wrote: > You might need STUN or something like that, but you shouldn’t need an > ALG. Well, if STUN is needed then this should be documented as well. It makes the TFTP client more complicated and it would break connectivity for legacy devices. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-2013288220-1438321351=:11810-- From nobody Fri Jul 31 06:21:31 2015 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 D32671A87A1; Fri, 31 Jul 2015 06:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 7YZFAor6TCeD; Fri, 31 Jul 2015 06:21:27 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3FFC1A87A9; Fri, 31 Jul 2015 06:21:27 -0700 (PDT) Received: from [192.168.1.3] (pool-71-108-120-69.lsanca.dsl-w.verizon.net [71.108.120.69]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6VDL3Wi006080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Jul 2015 06:21:05 -0700 (PDT) References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A Message-Id: X-Mailer: iPad Mail (12H143) From: Joe Touch Date: Fri, 31 Jul 2015 06:21:01 -0700 To: "Heatley, Nick" X-MailScanner-ID: t6VDL3Wi006080 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list , "behave@ietf.org" , Mark Smith , Mikael Abrahamsson Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 13:21:30 -0000 --Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable TFTP servers are typically reached at UDP port 69. It does not use ports or addresses in-band and thus should not need an ALG. Joe > On Jul 31, 2015, at 12:23 AM, Heatley, Nick wrote:= >=20 > Same for me. > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith > Sent: 31 July 2015 06:40 > To: Mikael Abrahamsson > Cc: v6ops list; behave@ietf.org > Subject: Re: [v6ops] protocols without need for ALG ? > =20 >=20 > On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" wrote: > > > > On Thu, 30 Jul 2015, Owen DeLong wrote: > > > >>> SSH/SCP - OK > >>> syslog - OK > >>> TFTP - OK ? > >> > >> > >> Should be OK, depending on which side is client. (client has to be the > >> private address/translated side of the connection). > > > > > > There are ALGs for TFTP from multiple vendors, and I seem to remember I h= ad problem performing TFTP download from behind a NAT, but I could be mistak= en. This should be investigated further. > > >=20 > I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer i= tself takes place over unspecified and unpredictable ports. This caused me s= ome grief in the past when trying to have a TFTP file transfer hold up a dia= l on demand link. >=20 > Regards, > Mark. >=20 > > --=20 > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named pe= rson(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any pu= rpose. =20 > =20 > We may monitor all incoming and outgoing emails in line with current legis= lation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruses= do not adversely affect you. >=20 > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertford= shire, AL10 9BW >=20 > =20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
TFTP servers are typically reached at UDP port 69.

It does not use ports or addresses in-band and thus should not need an ALG.

Joe

On Jul 31, 2015, at 12:23 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:

Same for me.

 

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith
Sent: 31 July 2015 06:40
To: Mikael Abrahamsson
Cc: v6ops list; behave@ietf.org
Subject: Re: [v6ops] protocols without need for ALG ?

 


On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Thu, 30 Jul 2015, Owen DeLong wrote:
>
>>>   SSH/SCP - OK
>>>   syslog  - OK
>>>   TFTP    - OK ?
>>
>>
>> Should be OK, depending on which side is client. (client has to be the
>> private address/translated side of the connection).
>
>
> There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further.
>

I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer itself takes place over unspecified and unpredictable ports. This caused me some grief in the past when trying to have a TFTP file transfer hold up a dial on demand link.

Regards,
Mark.

> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. 
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A-- From nobody Fri Jul 31 06:37:38 2015 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 59DF11A883A; Fri, 31 Jul 2015 06:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_37=1, 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 7UokycGj1bD4; Fri, 31 Jul 2015 06:37:30 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E2D1A8842; Fri, 31 Jul 2015 06:37:30 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so34330653wib.0; Fri, 31 Jul 2015 06:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5CgpmDwpfMJAgjtnYjfg6iaEr0VRBq2przQ7Rswdz/s=; b=FpCTmR2C4wjIHQvwcV0yI4sV8VlTyZay+97jB/DSPWkdx+79f1zxmlJ/CsPxlYUbQM FVb+nK29S1OJ4ARQoPOxSFVxOXrpjRHxrMJcjTqlNoPhFJFsQzRjeVNbdy5KreTCCLVk lGPiT1A0YCAU2p0iyJNYq/nRwVWgQVR0TJ/PYb69zpneiVHYbqB26Rwq/NSOsqXI141C pEXzpj5rO/4LUpdYWhHyUEubINI/6vC5NNVpP1meQrbe8cTygNrSukDIZj3f2QlGIWjo K1wqyY4TZuh0+JaTFQTUlsffid6RG7/uJTJuyZa0aW2LRgjO0BqS3lgy6RlSlh/dX1dk saQg== MIME-Version: 1.0 X-Received: by 10.194.108.5 with SMTP id hg5mr6384991wjb.25.1438349848909; Fri, 31 Jul 2015 06:37:28 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Fri, 31 Jul 2015 06:37:28 -0700 (PDT) In-Reply-To: <20150730205806.GI1667@cisco.com> References: <20150730205806.GI1667@cisco.com> Date: Fri, 31 Jul 2015 06:37:28 -0700 Message-ID: From: Ca By To: Toerless Eckert Content-Type: multipart/alternative; boundary=089e0103deface9f14051c2bebdd Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 13:37:36 -0000 --089e0103deface9f14051c2bebdd Content-Type: text/plain; charset=UTF-8 On Thursday, July 30, 2015, Toerless Eckert wrote: > For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 > for initial > autonomic connectivity, and the question of connecting this (at least > initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems > to be still > weak on a range of commonly used NOC tools. > > Ehhh. For something as forward looking as anima , it is unfortunate that you believe you will need to bring this technical debt with you. My suggeation is that you require ipv6 for this case. If you do not shed this requirement now, you will carry it with you forever. The iphone can require ipv6 apps, so can anima. CB > If i understand the NAT RFCs and behave output correctly, we primaerily > want ALGs to go the way of the dodo, so i was wondering if there might be > any crucial protocols between typical NOC equipment and network devices > that > would require ALGs. And better of course:knowing which protocols would be > fine > without ALG. > > Are there any lists about this (eg: what requires ALG ?) > > Wrt to what seems to be important between NOC and network devices: > > FTP - NOK (requires ALG) - IMHO not a problem > traceroute - ?? (initiated from v4 NOC) ?? > telnet - OK > ping - OK ? > SSH/SCP - OK > syslog - OK > TFTP - OK ? > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? > NTP - OK ??? > > For the following, that have extensible data-models (MIBs/OIDs, XML > schema etc.), > i can see that some NOC tools relying on them might not support > data-models > with IPv6, but that would be "fine" (aka: can't manage everything from > such tools, > but transport stack works): > > netconf - OK ? > SNMP - OK ? > > Whats the next most important NOC<->network management protocols... ? > > Thanks! > Toerless > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0103deface9f14051c2bebdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, July 30, 2015, Toerless Eckert <eckert@cisco.com> wrote:
For autonomic networking (ANIMA WG), we are planning to rely only o= n IPv6 for initial
autonomic connectivity, and the question of connecting this (at least initi= ally)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems t= o be still
weak on a range of commonly used NOC tools.


Ehhh. For something as forward looking= as anima , it is unfortunate that you believe you will need to bring this = technical debt with you.=C2=A0

My suggeation is th= at you require ipv6 for this case. If you do not shed this requirement now,= you will carry it with you forever.=C2=A0

The iph= one can require ipv6 apps, so can anima.=C2=A0

CB<= /div>
=C2=A0
If i understand the NAT RFCs and behave output correctly, we primaerily
want ALGs to go the way of the dodo, so i was wondering if there might be any crucial protocols between typical NOC equipment and network devices tha= t
would require ALGs. And better of course:knowing which protocols would be f= ine
without ALG.

Are there any lists about this (eg: what requires ALG ?)

Wrt to what seems to be important between NOC and network devices:

=C2=A0 =C2=A0FTP=C2=A0 =C2=A0 =C2=A0- NOK (requires ALG) - IMHO not a probl= em
=C2=A0 =C2=A0traceroute - ??=C2=A0 (initiated from v4 NOC) ??
=C2=A0 =C2=A0telnet=C2=A0 - OK
=C2=A0 =C2=A0ping=C2=A0 =C2=A0 - OK ?
=C2=A0 =C2=A0SSH/SCP - OK
=C2=A0 =C2=A0syslog=C2=A0 - OK
=C2=A0 =C2=A0TFTP=C2=A0 =C2=A0 - OK ?
=C2=A0 =C2=A0radius=C2=A0 - OK ? (i ran some tests, seemed to be fine)
=C2=A0 =C2=A0diameter/tacacs+ - OK ?
=C2=A0 =C2=A0NTP=C2=A0 =C2=A0 =C2=A0- OK ???

=C2=A0 =C2=A0For the following, that have extensible data-models (MIBs/OIDs= , XML schema etc.),
=C2=A0 =C2=A0i can see that some NOC tools relying on them might not suppor= t data-models
=C2=A0 =C2=A0with IPv6, but that would be "fine" (aka: can't = manage everything from such tools,
=C2=A0 =C2=A0but transport stack works):

=C2=A0 =C2=A0netconf - OK ?
=C2=A0 =C2=A0SNMP=C2=A0 =C2=A0 - OK ?

Whats the next most important NOC<->network management protocols... ?=

Thanks!
=C2=A0 =C2=A0 Toerless

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--089e0103deface9f14051c2bebdd-- From nobody Fri Jul 31 09:52:11 2015 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 BFCE31A9148; Fri, 31 Jul 2015 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, J_BACKHAIR_37=1, 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 L2o8mUJOo7y3; Fri, 31 Jul 2015 09:52:09 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9C11A90C8; Fri, 31 Jul 2015 09:52:09 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so65162648wic.0; Fri, 31 Jul 2015 09:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EaDaZgnl3owJfA8PKTFrawQv3rIC38OPVPQWHnb+oi0=; b=Bt+h3YAWIldiKHD00A5jF4/N1s02P99uBMN3rcp9ljFtRNo7JYxg3O/1koLkygmoBE 88l/rZj8h8vUDpmti4meO38KqaeuF4oYu/4FV7aaI8ZMVv85SO5ZyW9kU9liWWkf1XZG jp6rUMGkh+OsljrHde8JX+qL85b3vkY4IBJpZ1Z8ZWJe8tXNrkz9uCSoRnppmbu8My9W 2RK/s6Z9mV050tB8VJlrdjZrbjJQ4HMdYbQY7ykdutyli57n8XCsUOFExOhHcoFqORvA B1Dnio47FVXsTQlUtUgzadUV75a5hC3g+QMyZVEhz4C7N9KtA85MEr+NuD6EMrfbHzBe wmuA== X-Received: by 10.194.123.4 with SMTP id lw4mr7494370wjb.94.1438361528128; Fri, 31 Jul 2015 09:52:08 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id fs8sm8045444wjb.7.2015.07.31.09.52.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 09:52:07 -0700 (PDT) Message-ID: <55BBA7C1.3000502@gmail.com> Date: Sat, 01 Aug 2015 04:52:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ca By , Toerless Eckert References: <20150730205806.GI1667@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 16:52:10 -0000 On 01/08/2015 01:37, Ca By wrote: > On Thursday, July 30, 2015, Toerless Eckert wrote: > >> For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 >> for initial >> autonomic connectivity, and the question of connecting this (at least >> initially) >> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems >> to be still >> weak on a range of commonly used NOC tools. >> >> > Ehhh. For something as forward looking as anima , it is unfortunate that > you believe you will need to bring this technical debt with you. Yes, but we assume that during the phasing-in of autonomic operations, we will be forced to interface to legacy NOCs. Personally I think I disagree with NAT46 and NAT64 as the way to handle this, but Toerless is asking the right questions in order to have this debate over on the Anima list. Brian > > My suggeation is that you require ipv6 for this case. If you do not shed > this requirement now, you will carry it with you forever. > > The iphone can require ipv6 apps, so can anima. > > CB > > >> If i understand the NAT RFCs and behave output correctly, we primaerily >> want ALGs to go the way of the dodo, so i was wondering if there might be >> any crucial protocols between typical NOC equipment and network devices >> that >> would require ALGs. And better of course:knowing which protocols would be >> fine >> without ALG. >> >> Are there any lists about this (eg: what requires ALG ?) >> >> Wrt to what seems to be important between NOC and network devices: >> >> FTP - NOK (requires ALG) - IMHO not a problem >> traceroute - ?? (initiated from v4 NOC) ?? >> telnet - OK >> ping - OK ? >> SSH/SCP - OK >> syslog - OK >> TFTP - OK ? >> radius - OK ? (i ran some tests, seemed to be fine) >> diameter/tacacs+ - OK ? >> NTP - OK ??? >> >> For the following, that have extensible data-models (MIBs/OIDs, XML >> schema etc.), >> i can see that some NOC tools relying on them might not support >> data-models >> with IPv6, but that would be "fine" (aka: can't manage everything from >> such tools, >> but transport stack works): >> >> netconf - OK ? >> SNMP - OK ? >> >> Whats the next most important NOC<->network management protocols... ? >> >> Thanks! >> Toerless >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From nobody Fri Jul 31 11:16:36 2015 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 3EC761A904F; Thu, 30 Jul 2015 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_37=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 P84tSwZrt2ZC; Thu, 30 Jul 2015 13:58:08 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEB11A9046; Thu, 30 Jul 2015 13:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1478; q=dns/txt; s=iport; t=1438289889; x=1439499489; h=date:from:to:subject:message-id:mime-version; bh=HsrA8YTEcWcRTqWajoyXXGO6ukyWmKsZPE7ssL0u2DA=; b=HSAzor+Uz5qm8c5Ys1UlpJT/itlifIGrUtp95W70G6fICj39T3cp2mkG FzRtqmU6EJvJJeHESOAyBXAgafXp24GNZvhNYkZ3wLKLBJchjgoiHRSRb 99zYsFCCn1CK261z1DImsM8CAypX2W3yS3Ww/zneC7vwIq9/BCX4Yz/Wg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbBQBij7pV/4YNJK1cgxq9Z4k+OhIBAQEBAQEBgQqEURN7NAVKiEDFPAEBCAEBAQEBHZUIBY0/hziMRwKZOSaEHR6CfQEBAQ X-IronPort-AV: E=Sophos;i="5.15,578,1432598400"; d="scan'208";a="174050088" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 30 Jul 2015 20:58:08 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6UKw6bk027740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2015 20:58:07 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6UKw6tf019267; Thu, 30 Jul 2015 13:58:06 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6UKw6x0019266; Thu, 30 Jul 2015 13:58:06 -0700 Date: Thu, 30 Jul 2015 13:58:06 -0700 From: Toerless Eckert To: v6ops@ietf.org, behave@ietf.org Message-ID: <20150730205806.GI1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:16:34 -0700 Subject: [BEHAVE] protocols without need for ALG ? 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, 30 Jul 2015 20:58:09 -0000 For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 for initial autonomic connectivity, and the question of connecting this (at least initially) to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems to be still weak on a range of commonly used NOC tools. If i understand the NAT RFCs and behave output correctly, we primaerily want ALGs to go the way of the dodo, so i was wondering if there might be any crucial protocols between typical NOC equipment and network devices that would require ALGs. And better of course:knowing which protocols would be fine without ALG. Are there any lists about this (eg: what requires ALG ?) Wrt to what seems to be important between NOC and network devices: FTP - NOK (requires ALG) - IMHO not a problem traceroute - ?? (initiated from v4 NOC) ?? telnet - OK ping - OK ? SSH/SCP - OK syslog - OK TFTP - OK ? radius - OK ? (i ran some tests, seemed to be fine) diameter/tacacs+ - OK ? NTP - OK ??? For the following, that have extensible data-models (MIBs/OIDs, XML schema etc.), i can see that some NOC tools relying on them might not support data-models with IPv6, but that would be "fine" (aka: can't manage everything from such tools, but transport stack works): netconf - OK ? SNMP - OK ? Whats the next most important NOC<->network management protocols... ? Thanks! Toerless From nobody Fri Jul 31 11:16:37 2015 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 4EEE01ACE7A; Thu, 30 Jul 2015 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_22=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ywCvrZDZ6mco; Thu, 30 Jul 2015 14:43:50 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E621ACE71; Thu, 30 Jul 2015 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1859; q=dns/txt; s=iport; t=1438292630; x=1439502230; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=YMvRodV82tkvq4Nl4Z4+SYTIr1BVpGlubw0pAP7njz8=; b=XPWZ5i7k9kDp1/nMCO3g/czNFTLkozbcwQKWIu0IgTcBYRDLidzmzo6o FGsCsG3H9qs6MBZCEctzpMPCH8cgRq4WNSH7YAyuDIHE4zRKmrfFfMFJE IyS6rrzVA91OcUBhRBoWPo+e+R3bL0yrdpLMdEg8xR5S7Myw4JC/JCIw5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CRBQC9mbpV/5ldJa1cgxpUvRaHfAKBQDkTAQEBAQEBAYEKhCQBAQQnEz8QCxgJJQ8FSYhBxU0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi06EPEsHgxiBFAEEjT+HOIxHApk5JoQdHoJ9AQEB X-IronPort-AV: E=Sophos;i="5.15,579,1432598400"; d="scan'208";a="173575938" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 30 Jul 2015 21:43:49 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6ULhnjf018057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2015 21:43:49 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6ULhmXg026593; Thu, 30 Jul 2015 14:43:48 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6ULhmd0026592; Thu, 30 Jul 2015 14:43:48 -0700 Date: Thu, 30 Jul 2015 14:43:48 -0700 From: Toerless Eckert To: Owen DeLong Message-ID: <20150730214348.GA23601@cisco.com> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:16:34 -0700 Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 21:43:52 -0000 Thanks, Owen Wrt directionality: I was just wondering about embedded addresses or other difficult stuff. I was assuming 1:1 stateless v4<->v6 NAT, aka: "directionality" should not be an issue... Right ? Thanks for the other protocol list. Cheers Toerless On Thu, Jul 30, 2015 at 02:07:23PM -0700, Owen DeLong wrote: > FTP should be long deprecated for the most part anyway, however, PASV > mode FTP (if you must use FTP) should be OK without need of an ALG. > > > traceroute - ?? (initiated from v4 NOC) ?? > > telnet - OK > > ping - OK ? > > Should generally be OK. Requests must come from translated side of > the host pair. Responses can come from either side, but to be meaningful, > need to be responding from native side to translated side. > > > SSH/SCP - OK > > syslog - OK > > TFTP - OK ? > > Should be OK, depending on which side is client. (client has to be the > private address/translated side of the connection). > > > radius - OK ? (i ran some tests, seemed to be fine) > > diameter/tacacs+ - OK ? > > Should be OK, again, assuming favorable directionality. > > If RADIUS/TACACS server is on translated side and router is on native side, > then this will not work without an ALG or some other hackery. > > > NTP - OK ??? > > Same directionality considerations apply here. > > > For the following, that have extensible data-models (MIBs/OIDs, XML schema etc.), > > i can see that some NOC tools relying on them might not support data-models > > with IPv6, but that would be "fine" (aka: can't manage everything from such tools, > > but transport stack works): > > > > netconf - OK ? > > SNMP - OK ? > > Should be OK, assuming favorable directionality. > > HTTP > HTTPs > SMTP > IMAP > > sFlow/cFlow/etc. > > Owen From nobody Fri Jul 31 11:16:39 2015 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 E208D1B3111; Thu, 30 Jul 2015 22:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=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 0aSi2uqzbCGG; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4851B3118; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so25319171igb.0; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WEvRNGV4XYFlnXfR3WZlJ4xbS4LuvdL7XJ9TOJjdugE=; b=FZp4ZKD08y/4HsTgcYyyP0Fo15c7PP9Re47+6jvrBSpI7DH+m79eR9gXoyhCLNVfqf ffFCXWBQ4MJpVWbeQYsBmss+iNug48KZ+tLgYpFPSG2kCO0QzyTJwoEWubDRQ2AyAcaR CTwoLIDX2BsvhjdFQ3Z6pnTWfv2JnEwJziX72EC5D+Mc3c5IV8CUmFNE3lf4Lm7RXQrW dNtCjjCDuhbx+kpQlWFOSBM2Zaj+ycox7OQMYGTAnd5Z+EYz0A5O80wy6r1vhgLNdZRl fmyBHhbxPi2pNallZaAFvJzlAQ8z7F6288E12QTGxWiUbDXZtaYOjtsF1JhJwJnLOmrB +j8A== MIME-Version: 1.0 X-Received: by 10.50.88.65 with SMTP id be1mr2474058igb.95.1438321225035; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) Received: by 10.107.169.143 with HTTP; Thu, 30 Jul 2015 22:40:24 -0700 (PDT) Received: by 10.107.169.143 with HTTP; Thu, 30 Jul 2015 22:40:24 -0700 (PDT) In-Reply-To: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Date: Fri, 31 Jul 2015 15:40:24 +1000 Message-ID: From: Mark Smith To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e013d0dd6b0f475051c25414d Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:16:34 -0700 Cc: Owen DeLong , v6ops list , behave@ietf.org Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:40:27 -0000 --089e013d0dd6b0f475051c25414d Content-Type: text/plain; charset=UTF-8 On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" wrote: > > On Thu, 30 Jul 2015, Owen DeLong wrote: > >>> SSH/SCP - OK >>> syslog - OK >>> TFTP - OK ? >> >> >> Should be OK, depending on which side is client. (client has to be the >> private address/translated side of the connection). > > > There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further. > I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer itself takes place over unspecified and unpredictable ports. This caused me some grief in the past when trying to have a TFTP file transfer hold up a dial on demand link. Regards, Mark. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --089e013d0dd6b0f475051c25414d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Thu, 30 Jul 2015, Owen DeLong wrote:
>
>>> =C2=A0 SSH/SCP - OK
>>> =C2=A0 syslog=C2=A0 - OK
>>> =C2=A0 TFTP=C2=A0 =C2=A0 - OK ?
>>
>>
>> Should be OK, depending on which side is client. (client has to be= the
>> private address/translated side of the connection).
>
>
> There are ALGs for TFTP from multiple vendors, and I seem to remember = I had problem performing TFTP download from behind a NAT, but I could be mi= staken. This should be investigated further.
>

I'm pretty sure you'd need an ALG for TFTP over NAT,= as the file transfer itself takes place over unspecified and unpredictable= ports. This caused me some grief in the past when trying to have a TFTP fi= le transfer hold up a dial on demand link.

Regards,
Mark.

> --
> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--089e013d0dd6b0f475051c25414d-- From nobody Fri Jul 31 11:16:40 2015 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 DD1221A1A5F; Fri, 31 Jul 2015 05:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 VkvdnM5RVmZA; Fri, 31 Jul 2015 05:19:29 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E2D1A1A57; Fri, 31 Jul 2015 05:19:28 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 0d76bb55.2b9bd4c4d940.2190269.00-2461.6234745.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 Jul 2015 12:19:28 +0000 (UTC) X-MXL-Hash: 55bb67d010a9f991-70a57acb5dfee02961f8526b79da2fd264ff67be Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id ac76bb55.0.2190226.00-2146.6234630.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 Jul 2015 12:19:25 +0000 (UTC) X-MXL-Hash: 55bb67cd011d1b91-0065b5ded2378fdb1adbd1de065454db5b797db8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6VCJLx7021370; Fri, 31 Jul 2015 08:19:21 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6VCJBoY021305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Jul 2015 08:19:15 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 31 Jul 2015 12:19:07 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.63]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0224.002; Fri, 31 Jul 2015 08:19:07 -0400 From: "STARK, BARBARA H" To: Toerless Eckert , "v6ops@ietf.org" , "behave@ietf.org" Thread-Topic: [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp70rb1Fq++mESi4PQB2sD9p531f2EA Date: Fri, 31 Jul 2015 12:19:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61132AC5E09@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150730205806.GI1667@cisco.com> In-Reply-To: <20150730205806.GI1667@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.104.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ONaQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=BttOa0TPrj8A:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=pUsKtR-7xbNaotJVKlgA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:16:34 -0700 Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 12:19:30 -0000 > Wrt to what seems to be important between NOC and network devices: Is there ever a case where IPsec is used to establish a secure connection t= o the NOC equipment? I don't know -- I just know that IPsec is one of the m= ost common ALGs around. Barbara From nobody Fri Jul 31 11:16:41 2015 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 3C6871ABC0F; Fri, 31 Jul 2015 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_37=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 mlTjdUHke0aY; Fri, 31 Jul 2015 10:44:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BF01A89B5; Fri, 31 Jul 2015 10:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3154; q=dns/txt; s=iport; t=1438364663; x=1439574263; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=E6BOS8pbXJqyf4NZPVw19xH7s95wQevpjk41OzIkAWc=; b=QD4I8W+rPDnWCR1vWNjToF8fEBpR1eQPW0BzITiuz6HRvbdetMT+scOz 83y5dHVYoKTNw8RvfR7mjnhoSAF5VbHKlNkl+/6nLZgFPhZoqKW3fA7ib Ft58Mh2zIt9ZE1nLtKkaScb6mM3LkTKxxbcNfDvGrpV6wI/t68wu0EnqQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BrAwAKs7tV/4wNJK1bgxpUabw1CYF6CoUvSgKBMjgUAQEBAQEBAYEKhCMBAQEDAQEBASQTNAsFCwsYCSUPBRM2ExuICwgNx2kBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhQcHgxiBFAWNQIc4h12EagKZPyaEHR4xgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,585,1432598400"; d="scan'208";a="16707908" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2015 17:44:23 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6VHiMWP032708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2015 17:44:22 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6VHiLwi011016; Fri, 31 Jul 2015 10:44:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6VHiL9E011015; Fri, 31 Jul 2015 10:44:21 -0700 Date: Fri, 31 Jul 2015 10:44:21 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150731174421.GA9032@cisco.com> References: <20150730205806.GI1667@cisco.com> <55BBA7C1.3000502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BBA7C1.3000502@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:16:34 -0700 Cc: Ca By , "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 17:44:25 -0000 On Sat, Aug 01, 2015 at 04:52:17AM +1200, Brian E Carpenter wrote: > > Ehhh. For something as forward looking as anima , it is unfortunate that > > you believe you will need to bring this technical debt with you. > > > Yes, but we assume that during the phasing-in of autonomic operations, > we will be forced to interface to legacy NOCs. Right. It's just like siit-dc, just the opposite: We want to enable the IPv6 only autonomic network (like they an IPv6 only DC) of course to also encourage the IPv6 centric/only NOC but to get started also provide a simple, isolated, and easily removed solution (hack ?) to connect to legacy IPv4 NOC in our case (in siit-dc some legacy IPv4 (network)). > Personally I think I > disagree with NAT46 and NAT64 as the way to handle this Actually i now think siit-eam is the easiest way - which i think is an extension of stateless NAT64, but i don't claim i am using all the terminology right. > but Toerless > is asking the right questions in order to have this debate over on the > Anima list. Right. once i'm back from PTO after next week... Cheers toerless > > Brian > > > > > My suggeation is that you require ipv6 for this case. If you do not shed > > this requirement now, you will carry it with you forever. > > > > The iphone can require ipv6 apps, so can anima. > > > > CB > > > > > >> If i understand the NAT RFCs and behave output correctly, we primaerily > >> want ALGs to go the way of the dodo, so i was wondering if there might be > >> any crucial protocols between typical NOC equipment and network devices > >> that > >> would require ALGs. And better of course:knowing which protocols would be > >> fine > >> without ALG. > >> > >> Are there any lists about this (eg: what requires ALG ?) > >> > >> Wrt to what seems to be important between NOC and network devices: > >> > >> FTP - NOK (requires ALG) - IMHO not a problem > >> traceroute - ?? (initiated from v4 NOC) ?? > >> telnet - OK > >> ping - OK ? > >> SSH/SCP - OK > >> syslog - OK > >> TFTP - OK ? > >> radius - OK ? (i ran some tests, seemed to be fine) > >> diameter/tacacs+ - OK ? > >> NTP - OK ??? > >> > >> For the following, that have extensible data-models (MIBs/OIDs, XML > >> schema etc.), > >> i can see that some NOC tools relying on them might not support > >> data-models > >> with IPv6, but that would be "fine" (aka: can't manage everything from > >> such tools, > >> but transport stack works): > >> > >> netconf - OK ? > >> SNMP - OK ? > >> > >> Whats the next most important NOC<->network management protocols... ? > >> > >> Thanks! > >> Toerless > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Jul 31 11:21:17 2015 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 5E0AF1B32D2; Fri, 31 Jul 2015 00:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 vqMYohGJPllc; Fri, 31 Jul 2015 00:23:11 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828B51A1ABC; Fri, 31 Jul 2015 00:23:10 -0700 (PDT) Received: from [194.106.220.35] by server-10.bemta-14.messagelabs.com id DD/AB-01143-C522BB55; Fri, 31 Jul 2015 07:23:08 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-11.tower-91.messagelabs.com!1438327388!30948736!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30039 invoked from network); 31 Jul 2015 07:23:08 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-11.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2015 07:23:08 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:02 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:08 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 08:23:07 +0100 From: "Heatley, Nick" To: Owen DeLong , Toerless Eckert Thread-Topic: [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp6XZLyItFp5ECk8NAgQuQVk530cJyAgAC68MA= Date: Fri, 31 Jul 2015 07:23:07 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EEFB7C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:21:16 -0700 Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 07:23:12 -0000 =20>FTP should be long deprecated for the most part anyway, however, PASV= =20mode FTP (if you must use FTP) should be OK without need of an ALG. EPSV all the way. On a client on IPv4 side you need EPSV mode set to avoid ALG. On a server side on IPv4 it must be RFC2428 compliant i.e. to accept EPSV= . _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Fri Jul 31 11:21:18 2015 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 73A871A1ABC; Fri, 31 Jul 2015 00:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 hLgqDliCBkW2; Fri, 31 Jul 2015 00:23:11 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F2A1B32D1; Fri, 31 Jul 2015 00:23:10 -0700 (PDT) Received: from [85.158.136.35] by server-1.bemta-5.messagelabs.com id A6/C0-32615-D522BB55; Fri, 31 Jul 2015 07:23:09 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-125.messagelabs.com!1438327388!44368142!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18775 invoked from network); 31 Jul 2015 07:23:08 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-16.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2015 07:23:08 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:02 +0100 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:08 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 08:23:07 +0100 From: "Heatley, Nick" To: Mark Smith , Mikael Abrahamsson Thread-Topic: [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp6XZLyItFp5ECk8NAgQuQVk530cJyAgACHMACAAAgmAIAAK13A Date: Fri, 31 Jul 2015 07:23:07 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 31 Jul 2015 11:21:16 -0700 Cc: v6ops list , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 07:23:12 -0000 --_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtZSBmb3IgbWUuDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hcmsgU21pdGgNClNlbnQ6IDMxIEp1bHkgMjAxNSAwNjo0MA0KVG86 IE1pa2FlbCBBYnJhaGFtc3Nvbg0KQ2M6IHY2b3BzIGxpc3Q7IGJlaGF2ZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gcHJvdG9jb2xzIHdpdGhvdXQgbmVlZCBmb3IgQUxHID8NCg0KDQpP biAzMSBKdWwgMjAxNSAzOjExIHBtLCAiTWlrYWVsIEFicmFoYW1zc29uIiA8c3dtaWtlQHN3bS5w cC5zZTxtYWlsdG86c3dtaWtlQHN3bS5wcC5zZT4+IHdyb3RlOg0KPg0KPiBPbiBUaHUsIDMwIEp1 bCAyMDE1LCBPd2VuIERlTG9uZyB3cm90ZToNCj4NCj4+PiAgIFNTSC9TQ1AgLSBPSw0KPj4+ICAg c3lzbG9nICAtIE9LDQo+Pj4gICBURlRQICAgIC0gT0sgPw0KPj4NCj4+DQo+PiBTaG91bGQgYmUg T0ssIGRlcGVuZGluZyBvbiB3aGljaCBzaWRlIGlzIGNsaWVudC4gKGNsaWVudCBoYXMgdG8gYmUg dGhlDQo+PiBwcml2YXRlIGFkZHJlc3MvdHJhbnNsYXRlZCBzaWRlIG9mIHRoZSBjb25uZWN0aW9u KS4NCj4NCj4NCj4gVGhlcmUgYXJlIEFMR3MgZm9yIFRGVFAgZnJvbSBtdWx0aXBsZSB2ZW5kb3Jz LCBhbmQgSSBzZWVtIHRvIHJlbWVtYmVyIEkgaGFkIHByb2JsZW0gcGVyZm9ybWluZyBURlRQIGRv d25sb2FkIGZyb20gYmVoaW5kIGEgTkFULCBidXQgSSBjb3VsZCBiZSBtaXN0YWtlbi4gVGhpcyBz aG91bGQgYmUgaW52ZXN0aWdhdGVkIGZ1cnRoZXIuDQo+DQoNCkknbSBwcmV0dHkgc3VyZSB5b3Un ZCBuZWVkIGFuIEFMRyBmb3IgVEZUUCBvdmVyIE5BVCwgYXMgdGhlIGZpbGUgdHJhbnNmZXIgaXRz ZWxmIHRha2VzIHBsYWNlIG92ZXIgdW5zcGVjaWZpZWQgYW5kIHVucHJlZGljdGFibGUgcG9ydHMu IFRoaXMgY2F1c2VkIG1lIHNvbWUgZ3JpZWYgaW4gdGhlIHBhc3Qgd2hlbiB0cnlpbmcgdG8gaGF2 ZSBhIFRGVFAgZmlsZSB0cmFuc2ZlciBob2xkIHVwIGEgZGlhbCBvbiBkZW1hbmQgbGluay4NCg0K UmVnYXJkcywNCk1hcmsuDQoNCj4gLS0NCj4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBz d21pa2VAc3dtLnBwLnNlPG1haWx0bzpzd21pa2VAc3dtLnBwLnNlPg0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCk5PVElDRSBBTkQgRElTQ0xB SU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVk IGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlz IGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFu eSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5n IGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBz dGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBm cm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1 cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0 ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBO dW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNl LCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== --_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNhbWUgZm9yIG1lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i Pk1hcmsgU21pdGg8YnI+DQo8Yj5TZW50OjwvYj4gMzEgSnVseSAyMDE1IDA2OjQwPGJyPg0KPGI+ VG86PC9iPiBNaWthZWwgQWJyYWhhbXNzb248YnI+DQo8Yj5DYzo8L2I+IHY2b3BzIGxpc3Q7IGJl aGF2ZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBwcm90b2NvbHMg d2l0aG91dCBuZWVkIGZvciBBTEcgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PGJyPg0KT24gMzEgSnVsIDIwMTUg MzoxMSBwbSwgJnF1b3Q7TWlrYWVsIEFicmFoYW1zc29uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c3dtaWtlQHN3bS5wcC5zZSI+c3dtaWtlQHN3bS5wcC5zZTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgMzAgSnVsIDIwMTUsIE93ZW4gRGVMb25nIHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7IFNTSC9TQ1AgLSBPSzxicj4NCiZndDsm Z3Q7Jmd0OyAmbmJzcDsgc3lzbG9nJm5ic3A7IC0gT0s8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7 IFRGVFAmbmJzcDsgJm5ic3A7IC0gT0sgPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBTaG91bGQgYmUgT0ssIGRlcGVuZGluZyBvbiB3aGljaCBzaWRlIGlzIGNsaWVu dC4gKGNsaWVudCBoYXMgdG8gYmUgdGhlPGJyPg0KJmd0OyZndDsgcHJpdmF0ZSBhZGRyZXNzL3Ry YW5zbGF0ZWQgc2lkZSBvZiB0aGUgY29ubmVjdGlvbikuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZXJlIGFyZSBBTEdzIGZvciBURlRQIGZyb20gbXVsdGlwbGUgdmVuZG9ycywgYW5k IEkgc2VlbSB0byByZW1lbWJlciBJIGhhZCBwcm9ibGVtIHBlcmZvcm1pbmcgVEZUUCBkb3dubG9h ZCBmcm9tIGJlaGluZCBhIE5BVCwgYnV0IEkgY291bGQgYmUgbWlzdGFrZW4uIFRoaXMgc2hvdWxk IGJlIGludmVzdGlnYXRlZCBmdXJ0aGVyLjxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwPkkn bSBwcmV0dHkgc3VyZSB5b3UnZCBuZWVkIGFuIEFMRyBmb3IgVEZUUCBvdmVyIE5BVCwgYXMgdGhl IGZpbGUgdHJhbnNmZXIgaXRzZWxmIHRha2VzIHBsYWNlIG92ZXIgdW5zcGVjaWZpZWQgYW5kIHVu cHJlZGljdGFibGUgcG9ydHMuIFRoaXMgY2F1c2VkIG1lIHNvbWUgZ3JpZWYgaW4gdGhlIHBhc3Qg d2hlbiB0cnlpbmcgdG8gaGF2ZSBhIFRGVFAgZmlsZSB0cmFuc2ZlciBob2xkIHVwIGEgZGlhbCBv biBkZW1hbmQgbGluay48bzpwPjwvbzpwPjwvcD4NCjxwPlJlZ2FyZHMsPGJyPg0KTWFyay48bzpw PjwvbzpwPjwvcD4NCjxwPiZndDsgLS0gPGJyPg0KJmd0OyBNaWthZWwgQWJyYWhhbXNzb24mbmJz cDsgJm5ic3A7IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86c3dtaWtlQHN3bS5wcC5zZSI+c3dtaWtl QHN3bS5wcC5zZTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxp bmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCg0KPFA+Tk9USUNFIEFORCBESVNDTEFJ TUVSPEJSPlRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRl ZCANCmZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiZuYnNwOyBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCANCm5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBk ZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgDQpkaXNjbG9zZSBv ciB1c2UgZm9yIGFueSBwdXJwb3NlLiZuYnNwOyA8QlI+Jm5ic3A7PEJSPldlIG1heSBtb25pdG9y IGFsbCBpbmNvbWluZyANCmFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQg bGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gDQplbnN1cmUgdGhhdCB0aGlzIGVt YWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFp bnMgDQp5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFk dmVyc2VseSBhZmZlY3QgeW91LiA8L1A+DQo8UD5FRSBMaW1pdGVkPEJSPlJlZ2lzdGVyZWQgaW4g RW5nbGFuZCBhbmQgV2FsZXM8QlI+Q29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogDQowMjM4MjE2 MTxCUj5SZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBX YXksIEhhdGZpZWxkLCANCkhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXPC9QPg0KPFA+Jm5ic3A7PC9Q Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_-- From nobody Fri Jul 31 11:41:47 2015 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 C98171B3476; Fri, 31 Jul 2015 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.21 X-Spam-Level: X-Spam-Status: No, score=-13.21 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, J_BACKHAIR_37=1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 uqYmTZNh6qtt; Fri, 31 Jul 2015 11:41:43 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3614B1B3472; Fri, 31 Jul 2015 11:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13157; q=dns/txt; s=iport; t=1438368103; x=1439577703; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=fusxcXN+BnkpsK6oNMqDohRb1ve9KbfWIIUgCWgPdL4=; b=WbUXdOMXL07R5tg+gMxWVFTCTqpRI3jkhRU622q6bn+AFej7uPp5MpCo U44VTa6zDawAWaFceaBqAcqIEZMGQQFn9RQcOjQEIFkfu+ZiTapUlcIoT h86MhTbX0NqNkp2N+NOoobQ7Z8BFo1XttuA5xEPrsvy4QkZ44/Gg6bkLV c=; X-IronPort-AV: E=Sophos; i="5.15,586,1432598400"; d="scan'208,217"; a="16718101" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2015 18:41:42 +0000 Received: from [10.24.84.19] ([10.24.84.19]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6VIffMi005487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2015 18:41:42 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Fri, 31 Jul 2015 11:41:40 -0700 Message-Id: <43CF0BAE-637D-4462-B067-3ED16E7A5D29@cisco.com> References: <20150730205806.GI1667@cisco.com> To: Ca By , Toerless Eckert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 18:41:45 -0000 --Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31-Jul-2015 06:37 am, Ca By wrote:=20 >=20 >=20 > On Thursday, July 30, 2015, Toerless Eckert > wrote: > For autonomic networking (ANIMA WG), we are planning to rely only on = IPv6 for initial > autonomic connectivity, and the question of connecting this (at least = initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport = seems to be still > weak on a range of commonly used NOC tools. >=20 >=20 > Ehhh. For something as forward looking as anima , it is unfortunate = that you believe you will need to bring this technical debt with you.=20 +1. Let's please kill ALGs. See below. > My suggeation is that you require ipv6 for this case. If you do not = shed this requirement now, you will carry it with you forever.=20 >=20 > The iphone can require ipv6 apps, so can anima.=20 >=20 > CB > =20 > If i understand the NAT RFCs and behave output correctly, we = primaerily > want ALGs to go the way of the dodo, so i was wondering if there might = be > any crucial protocols between typical NOC equipment and network = devices that > would require ALGs. And better of course:knowing which protocols would = be fine > without ALG. >=20 > Are there any lists about this (eg: what requires ALG ?) >=20 > Wrt to what seems to be important between NOC and network devices: >=20 > FTP - NOK (requires ALG) - IMHO not a problem FTP is a troublesome case. All modern FTP clients default to using PASV = -- IE 6 was the last holdout that didn't do PASV and thus broke with NAT = or required an FTP ALG. However, PASV doesn't work with IPv6 servers = which need EPSV. So certain NAT46 and NAT64 cases will break unless = there is an FTP ALG. Hence, BEHAVE wrote RFC6384 which explains NAT64 = case, but there isn't a document explaining the 464XLAT situation with = FTP. Better to just declare FTP dead. Passive (both PASV and EPSV) are = vulnerable to a connection theft (see http://cr.yp.to/ftp/security.html = ). For whatever it's worth, both = Chrome and Firefox have open bugs to remove FTP from both of those = browsers. Instead of FTP, profile that anima has to use HTTP or HTTPS. > traceroute - ?? (initiated from v4 NOC) ?? OK. > telnet - OK > ping - OK ? > SSH/SCP - OK > syslog - OK > TFTP - OK ? TFTP breaks if the NAT (or firewall) have Address and Port-Dependent = Filtering behavior (defined at https://tools.ietf.org/html/rfc4787 = #section-5). This is because TFTP = client sends a packet to the server's port 69, and the server's response = is sent from an ephemeral port (rather than from port 69). Some NATs = and some firewalls change their filtering behavior if the destination = port is 69, and because behavior changes based on the application (TFTP) = many people would consider that to be an "ALG", although the NAT is not = modifying the application payload, which is arguably the strict = definition of an ALG. Instead of FTP, profile that anima has to use HTTP or HTTPS. > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? > NTP - OK ??? >=20 > For the following, that have extensible data-models (MIBs/OIDs, XML = schema etc.), > i can see that some NOC tools relying on them might not support = data-models > with IPv6, but that would be "fine" (aka: can't manage everything = from such tools, > but transport stack works): >=20 > netconf - OK ? > SNMP - OK ? SNMP often contains IP addresses (e.g., IP address of configured = interfaces) which can confuse a management system that isn't aware of = NAT. We certainly don't want an ALG to fiddle with SNMP, though, that = would be a nightmare. Polling SNMP across a firewall or NAT is = problematic or impossible (and ALG can't fix that). -d >=20 > Whats the next most important NOC<->network management protocols... ? >=20 > Thanks! > Toerless >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 31-Jul-2015 06:37 am, Ca By <cb.list6@gmail.com> = wrote:


On Thursday, = July 30, 2015, Toerless Eckert <eckert@cisco.com> wrote:
For autonomic networking (ANIMA WG), we are = planning to rely only on IPv6 for initial
autonomic connectivity, and the question of connecting this (at least = initially)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport = seems to be still
weak on a range of commonly used NOC tools.


Ehhh. For something as forward looking as anima , it is = unfortunate that you believe you will need to bring this technical debt = with you. 

+1.=  Let's please kill ALGs.


See below.


My suggeation is that you require ipv6 for this case. If you = do not shed this requirement now, you will carry it with you = forever. 

The iphone can require ipv6 apps, so can = anima. 

CB
 
If i understand the NAT RFCs and behave output correctly, we = primaerily
want ALGs to go the way of the dodo, so i was wondering if there might = be
any crucial protocols between typical NOC equipment and network devices = that
would require ALGs. And better of course:knowing which protocols would = be fine
without ALG.

Are there any lists about this (eg: what requires ALG ?)

Wrt to what seems to be important between NOC and network devices:

   FTP     - NOK (requires ALG) - IMHO not a = problem

FTP is a troublesome case.  All modern FTP = clients default to using PASV -- IE 6 was the last holdout that didn't = do PASV and thus broke with NAT or required an FTP ALG.  However, =  PASV doesn't work with IPv6 servers which need EPSV.  So = certain NAT46 and NAT64 cases will break unless there is an FTP ALG. =  Hence, BEHAVE wrote RFC6384 which explains NAT64 case, but there = isn't a document explaining the 464XLAT situation with FTP.  Better = to just declare FTP dead.  Passive (both PASV and EPSV) are = vulnerable to a connection theft (see http://cr.yp.to/ftp/security.html).  For whatever = it's worth, both Chrome and Firefox have open bugs to remove FTP from = both of those browsers.

Instead = of FTP, profile that anima has to use HTTP or HTTPS.


   traceroute - ??  (initiated from v4 NOC) ??

OK.


   telnet  - OK
   ping    - OK ?
   SSH/SCP - OK
   syslog  - OK
   TFTP    - OK ?


TFTP breaks if the = NAT (or firewall) have Address and Port-Dependent Filtering behavior = (defined at https://tools.ietf.org/html/rfc4787#section-5). =  This is because TFTP client sends a packet to the server's port = 69, and the server's response is sent from an ephemeral port (rather = than from port 69).  Some NATs and some firewalls change their = filtering behavior if the destination port is 69, and because behavior = changes based on the application (TFTP) many people would consider that = to be an "ALG", although the NAT is not modifying the application = payload, which is arguably the strict definition of an = ALG.

Instead of FTP, profile = that anima has to use HTTP or HTTPS.


   radius  - OK ? (i ran some tests, seemed to be = fine)
   diameter/tacacs+ - OK ?
   NTP     - OK ???

   For the following, that have extensible data-models = (MIBs/OIDs, XML schema etc.),
   i can see that some NOC tools relying on them might not = support data-models
   with IPv6, but that would be "fine" (aka: can't manage = everything from such tools,
   but transport stack works):

   netconf - OK ?
   SNMP    - OK ?

SNMP often contains IP addresses (e.g., IP address = of configured interfaces) which can confuse a management system that = isn't aware of NAT.  We certainly don't want an ALG to fiddle with = SNMP, though, that would be a nightmare.  Polling SNMP across a = firewall or NAT is problematic or impossible (and ALG can't fix = that).

-d



Whats the next most important NOC<->network management = protocols... ?

Thanks!
    Toerless

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


= --Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4-- From nobody Fri Jul 31 12:14:09 2015 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 C407A1B2DFF; Fri, 31 Jul 2015 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 8LUOyuwmTGZP; Fri, 31 Jul 2015 12:14:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEC51B2D4F; Fri, 31 Jul 2015 12:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1978; q=dns/txt; s=iport; t=1438370046; x=1439579646; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y9jQyGRety5YOHAZnjdNbzagx/cAIvESdk/pNmMUl1k=; b=Shx1QZ31mLhUNUOsW6tCxMy7sgfQqcCbftx62YL6eH8DMtlp8Iw43fsZ +MGLttwUZ4Xy8+ebxSmJT8M9vRO7ZqkNfAquMesSbvOefMxWKqyBMaHyb KPCAH9jnvVO+wlAWPb9KwJVjUDcB2PR+kOHnJ2eHUQJ4IJTCkY51vRWYd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9BQBEyLtV/4MNJK1bDoMMVGkGvjMKhS9KAoEyOxEBAQEBAQEBgQqEJAEBBAEBATc0CxACAQgYFgEHECcLJQIEAQ0FiC4Nx0YBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhQcHEwGEGAWFZY8TAYoMgjyBR5QTg2Umgz8+b4EHBxcjgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,586,1432598400"; d="scan'208";a="16722737" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2015 19:14:04 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6VJE0bZ010123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 19:14:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.77]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 14:14:00 -0500 From: "Senthil Sivakumar (ssenthil)" To: Joe Touch , Owen DeLong , "Toerless Eckert (eckert)" Thread-Topic: [BEHAVE] [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp4WemgLTWIcUiyGhVGVVQ3qJ301TGAgAAEyQCAASrNgA== Date: Fri, 31 Jul 2015 19:13:59 +0000 Message-ID: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <55BA960E.7010700@isi.edu> In-Reply-To: <55BA960E.7010700@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.150.24.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CDC18AAA2B2AA4B8A046C6C838CE992@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 19:14:07 -0000 On 7/30/15, 5:24 PM, "Behave on behalf of Joe Touch" wrote: > > >On 7/30/2015 2:07 PM, Owen DeLong wrote: >>=20 >>> On Jul 30, 2015, at 13:58 , Toerless Eckert wrote: >>> >>> For autonomic networking (ANIMA WG), we are planning to rely only on >>>IPv6 for initial >>> autonomic connectivity, and the question of connecting this (at least >>>initially) >>> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport >>>seems to be still >>> weak on a range of commonly used NOC tools. >>> >>> If i understand the NAT RFCs and behave output correctly, we primaerily >>> want ALGs to go the way of the dodo, > >NATs too, if we're taking requests... > >... >>> Wrt to what seems to be important between NOC and network devices: >>> >>> FTP - NOK (requires ALG) - IMHO not a problem >>=20 >> FTP should be long deprecated for the most part anyway, however, PASV >> mode FTP (if you must use FTP) should be OK without need of an ALG. > >FTP has security problems but anonymous mode access to files is still >used. As noted, PASV avoids the need for ALG in-band address translation. > >All the listed protocols should be OK if the client is behind the NAT >(as noted) *or* if the NAT is configured to forward those services to a >particular private-side host. > >Other ALG protocols not on your list: > > web: > HTTP (mostly to hijack initial login screens, > somtimes to insert tracking or ads) > > teleconferencing/media: > Apple iChat > H.323 > MGCP (media gateway) > RTSP (realtime streaming) > SCCP (Cisco call signalling) > SIP > > remote functions: > RPC (Sun, Microsoft) > SQL > > tunneling: > PPTP Also, include LDAP, DNS and Netbios ALGs to the list. Senthil > >--- > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From nobody Fri Jul 31 13:17:24 2015 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 383661ACD35; Fri, 31 Jul 2015 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0ia0SYH5IMeG; Fri, 31 Jul 2015 13:17:22 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB22C1A88D0; Fri, 31 Jul 2015 13:17:21 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=46204 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZLGk1-0000Gg-GC; Fri, 31 Jul 2015 22:17:17 +0200 Date: Fri, 31 Jul 2015 22:17:16 +0200 From: Tore Anderson To: Toerless Eckert Message-ID: <20150731221716.5729154a@envy.fud.no> In-Reply-To: <20150731174421.GA9032@cisco.com> References: <20150730205806.GI1667@cisco.com> <55BBA7C1.3000502@gmail.com> <20150731174421.GA9032@cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 20:17:23 -0000 * Toerless Eckert > On Sat, Aug 01, 2015 at 04:52:17AM +1200, Brian E Carpenter wrote: > > Yes, but we assume that during the phasing-in of autonomic > > operations, we will be forced to interface to legacy NOCs. > > Right. It's just like siit-dc, just the opposite: We want to enable > the IPv6 only autonomic network (like they an IPv6 only DC) of course > to also encourage the IPv6 centric/only NOC but to get started also > provide a simple, isolated, and easily removed solution (hack ?) to > connect to legacy IPv4 NOC in our case (in siit-dc some legacy IPv4 > (network)). Yep, but be aware that with SIIT you will need to identify all the IPv6 endpoints you want the IPv4-only NOC folks to be able to access. These endpoints need either to be provisioned with an IPv4-translatable IPv6 address (traditional SIIT), or get an IPv4 mapping provisioned on the protocol translator (SIIT-DC style deployment with EAMs). You could also use Stateful NAT64 (RFC6146) with statically configured BIB entries to accomplish pretty much the same thing as the SIIT-DC approach, but you do get a lot of superfluous baggage that way (all the stateful connection/session tracking stuff). Anyway if the IPv6-only autonomic network is very dynamic in nature and/or have a large number of managed endpoints that must be reachable from the IPv4-only NOC, that requirement could possibly be problematic. BTW you asked about traceroute, and I don't think anyone answered, so: ICMPv6 packets originated by IPv6 hops behind the translator (that are not provisioned with an IPv4-translatable IPv6 address) will appear as originating from a "random" IPv4 address (which could repeat multiple times in the path). That could possibly be confusing to NOC staff, so I'd suggest giving the RFC6791 addresses descriptive PTR records in DNS ("this-apparent-ipv4-hop-really-represents-an-ipv6-router-in-the-autonomic-network-see-rfc6791.example.com"). > Actually i now think siit-eam is the easiest way - which i think is > an extension of stateless NAT64, but i don't claim i am using all > the terminology right. Let me know if you want some help or pointers on how to set up a stateless translator for testing purposes. Or you could use one of mine, as it works just as well over the public internet too (as long as the IPv6 endpoints you want to manage are numbered with globally reachable addresses). I'd be happy to assist. Tore From nobody Fri Jul 31 13:31:49 2015 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 220FC1ACE93; Fri, 31 Jul 2015 13:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jEga1Mp4SalP; Fri, 31 Jul 2015 13:31:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F9A1ACE81; Fri, 31 Jul 2015 13:31:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 493DBE1BF; Fri, 31 Jul 2015 16:49:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BE02563AEC; Fri, 31 Jul 2015 16:31:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A2A0463751; Fri, 31 Jul 2015 16:31:44 -0400 (EDT) From: Michael Richardson To: Toerless Eckert In-Reply-To: <20150730205806.GI1667@cisco.com> References: <20150730205806.GI1667@cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 20:31:48 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > radius - OK ? Classic RADIUS has an MD5 based authenticator which depends upon the IP address. It can sometimes be made to work through NAPTs, but in general it doesn't. Newer mechanisms get rid of this, replacing it all with DTLS, which doesn't care, but the classic stuff is pretty widespread. On the other hand, it is easily proxied from IPv6 to IPv4 should the radius server be unable to speak IPv6. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVbvbMICLcPvd0N1lAQJkgwf9E/Evj9G9Sl9lSPXzRu+t5McKpIux9hZu hlWRetl7xlI0vxei5q7IWaCT4ELqk+KxbUHM0qZySH6DuFsx+ua95lqiYS6K3ZWT WOSs+IODVC7zonrZLOQHddHLX1PwrCBom4kX1la8fEU4vWH5Oh/kVi1eUISb869I rHGILT6bQO0MWf5xbIcI7jfbqbtTnELIyGEjKRudi1qbc//DQ4Smi1VEGhFlPx7w MpOnky7Mk2x3+9xifENdOsHMP7WX5T6535eEu8pYgIW3pOAaKzbkTNlMBMrKx+5v dPa9/Y69dyovHF87eiRbm837EIU5CrznxqkXdzdwtz81qiT6zoUVpg== =7AV2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 31 16:45:47 2015 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 4B1571ACCFB; Fri, 31 Jul 2015 16:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 5TXbt0vgwu4N; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FE81ACCF4; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) Received: by iodd187 with SMTP id d187so99855310iod.2; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WZATmvRdK9x4BzUljz3+Y/cS+x5yAutmbSzMqTIHHew=; b=RUCcxQ/mKN824quzhEAB1rfldNBEf/UmowzQ8mx+R72qFYr88I9WLqxgHsYbm0cdbM BNbus8ibUr+XBwb9ZtBD6QRTFvOx6/nDx4mgmPseIAeOHmwuwQdIJ/AqYE+MWOvLqbTF EgetUNtB1+B/8VDfSCptbnVhXUW61glus+MMzOJeBo1j6AQkQhHr6A4CAePxwLjZcQKy 4Oc6d+VBWJ6Lon+NREkyw2f/EMCkOME1JZqZKQFmEQX3a6PMJmhHNzmmIxSOnFCEp5ms WJP79SYw/H5t4xhWOk4s5kLvG+WfE6hz0VWhU0aooWYGyb796crqXBg4DaW9R5RSFpvC a9bg== X-Received: by 10.107.134.83 with SMTP id i80mr9209178iod.123.1438386343083; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Fri, 31 Jul 2015 16:45:13 -0700 (PDT) In-Reply-To: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Mark Smith Date: Sat, 1 Aug 2015 09:45:13 +1000 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "behave@ietf.org" , v6ops list , "Heatley, Nick" , Mikael Abrahamsson Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 23:45:45 -0000 On 31 July 2015 at 23:21, Joe Touch wrote: > TFTP servers are typically reached at UDP port 69. > > It does not use ports or addresses in-band and thus should not need an ALG. Hmm, to my mind, an "ALG" is necessary if something about the protocol needs to be understood e.g., look for/change in-band ports or addresses, and possibly set up corresponding state or temporary access list/firewall permissions for related traffic. In the case of TFTP, it is the "TID"s: "The transfer identifiers (TID's) used by TFTP are passed to the Datagram layer to be used as ports; therefore they must be between 0 and 65,535. The initialization of TID's is discussed in the section on initial connection protocol." " A requesting host chooses its source TID as described above, and sends its initial request to the known TID 69 decimal (105 octal) on the serving host. The response to the request, under normal operation, uses a TID chosen by the server as its source TID and the TID chosen for the previous message by the requestor as its destination TID. The two chosen TID's are then used for the remainder of the transfer." I think a server could choose to continue to use 69 as its TID for the full transfer, however in my case it didn't. I still remember it today because I was only able to get around the unpredictable TID selection on both ends by using just host IP addresses, which had some risks because it was a very coarse way of selecting "interesting" dial-on-demand traffic to hold the link up. So if in Toerless's scenario it is stateless 1:1 translation between IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. However, if the translation is stateful because translation between IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a mapping of some form. Regards, Mark. > > Joe > > On Jul 31, 2015, at 12:23 AM, Heatley, Nick wrote: > > Same for me. > > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith > Sent: 31 July 2015 06:40 > To: Mikael Abrahamsson > Cc: v6ops list; behave@ietf.org > Subject: Re: [v6ops] protocols without need for ALG ? > > > > > On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" wrote: >> >> On Thu, 30 Jul 2015, Owen DeLong wrote: >> >>>> SSH/SCP - OK >>>> syslog - OK >>>> TFTP - OK ? >>> >>> >>> Should be OK, depending on which side is client. (client has to be the >>> private address/translated side of the connection). >> >> >> There are ALGs for TFTP from multiple vendors, and I seem to remember I >> had problem performing TFTP download from behind a NAT, but I could be >> mistaken. This should be investigated further. >> > > I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer > itself takes place over unspecified and unpredictable ports. This caused me > some grief in the past when trying to have a TFTP file transfer hold up a > dial on demand link. > > Regards, > Mark. > >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or use > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachments > are free from any virus, but it remains your responsibility to ensure that > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 31 17:47:11 2015 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 560B81ACE31; Fri, 31 Jul 2015 17:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, T_RP_MATCHES_RCVD=-0.01] 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 cPaI4KM_T-zf; Fri, 31 Jul 2015 17:47:07 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8931ACE2F; Fri, 31 Jul 2015 17:47:07 -0700 (PDT) Received: from [128.9.184.71] ([128.9.184.71]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t710kaIk011548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 17:46:37 -0700 (PDT) To: Mark Smith References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55BC16EB.8060007@isi.edu> Date: Fri, 31 Jul 2015 17:46:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t710kaIk011548 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "behave@ietf.org" , v6ops list , Mikael Abrahamsson , "Heatley, Nick" , touch@isi.edu Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 01 Aug 2015 00:47:08 -0000 Hi, Mark, On 7/31/2015 4:45 PM, Mark Smith wrote: > On 31 July 2015 at 23:21, Joe Touch wrote: >> TFTP servers are typically reached at UDP port 69. >> >> It does not use ports or addresses in-band and thus should not need an ALG. > > Hmm, to my mind, an "ALG" is necessary if something about the protocol > needs to be understood e.g., look for/change in-band ports or > addresses, and possibly set up corresponding state or temporary access > list/firewall permissions for related traffic. > > In the case of TFTP, it is the "TID"s: > > "The transfer identifiers (TID's) used by > TFTP are passed to the Datagram layer to be used as ports; therefore > they must be between 0 and 65,535. The initialization of TID's is > discussed in the section on initial connection protocol." > > " A > requesting host chooses its source TID as described above, and sends > its initial request to the known TID 69 decimal (105 octal) on the > serving host. The response to the request, under normal operation, > uses a TID chosen by the server as its source TID and the TID chosen > for the previous message by the requestor as its destination TID. > The two chosen TID's are then used for the remainder of the transfer." Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair. It works a bit like FTP in that it "hands off" the transfer to the server port indicated by the server-side TID after the initial request. > I think a server could choose to continue to use 69 as its TID for the > full transfer, however in my case it didn't. It never will. The first packet is supposed to have a destination TID of 69 but the rest of the session uses TIDs chosen by each end. client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69 server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X, which is where the rest of the transfer stays until a new TID is selected. > I still remember it today > because I was only able to get around the unpredictable TID selection > on both ends by using just host IP addresses, which had some risks > because it was a very coarse way of selecting "interesting" > dial-on-demand traffic to hold the link up. I'm not sure what you were doing; "using just host IP addresses" doesn't fix the issue because TFTP still wants to pick TIDs, and the UDP ports vary when the TIDs do. > So if in Toerless's scenario it is stateless 1:1 translation between > IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. > However, if the translation is stateful because translation between > IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a > mapping of some form. So first let me backtrack - TFTP requires an ALG to work through a NAT even when the client is on the private side. The return traffic content needs to be inspected to be able to update the private:public translation entry. I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an ALG. I can't imagine how to make sense of it safely in a non-1:1 case. Note that the whole point of TFTP is to be used on a LAN only. It has zero security, and it's easily possible that the translation entry could inadvertently affect some other UDP translation entry. Joe From nobody Fri Jul 31 19:50:47 2015 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 85C221AC416; Fri, 31 Jul 2015 19:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 lOwYrftr6ANc; Fri, 31 Jul 2015 19:50:43 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173251AC400; Fri, 31 Jul 2015 19:50:43 -0700 (PDT) Received: by iodd187 with SMTP id d187so102048428iod.2; Fri, 31 Jul 2015 19:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W46HeJg1MXGcktwkYChajwa/JGLTXl3ABLpd3s+jLA4=; b=pwkeAaKqSk9W1zIPS55RNCKhIcMsym3TWRgkvKlpeK7sBgdDVM5EfemexXeCgMRk37 0Z/Ah+uzMitjEaB3k+0gB7EhBSeZykkBRofjyuhqhQIBVVqtJdYPix1O9oNlvGIeiQvL pPRcY/4PRm6Z0PbNnFdJPlMmhEsU4w1jb4tfFI8CG9m7kVEOmKOznHBEm/6oA7NjEGaP cCky4a41CS4qQk3CBZOSvK7+LqPAtqCY9Gn2LyeyjuYtbF1Znh8Bf3x+ThhhhIXsNCex yRAqpNKHNuSm+DYwHOelmA6wYLeYp6m+4z/nwrKnp7+GK7kEXW2xcBqFc7/pACL2k7DM vJVw== X-Received: by 10.107.155.74 with SMTP id d71mr11110680ioe.41.1438397442585; Fri, 31 Jul 2015 19:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Fri, 31 Jul 2015 19:50:13 -0700 (PDT) In-Reply-To: <55BC16EB.8060007@isi.edu> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <55BC16EB.8060007@isi.edu> From: Mark Smith Date: Sat, 1 Aug 2015 12:50:13 +1000 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "behave@ietf.org" , v6ops list , "Heatley, Nick" , Mikael Abrahamsson Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ? 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, 01 Aug 2015 02:50:44 -0000 Hi Joe, On 1 August 2015 at 10:46, Joe Touch wrote: > Hi, Mark, > > On 7/31/2015 4:45 PM, Mark Smith wrote: >> On 31 July 2015 at 23:21, Joe Touch wrote: >>> TFTP servers are typically reached at UDP port 69. >>> >>> It does not use ports or addresses in-band and thus should not need an ALG. >> >> Hmm, to my mind, an "ALG" is necessary if something about the protocol >> needs to be understood e.g., look for/change in-band ports or >> addresses, and possibly set up corresponding state or temporary access >> list/firewall permissions for related traffic. >> >> In the case of TFTP, it is the "TID"s: >> >> "The transfer identifiers (TID's) used by >> TFTP are passed to the Datagram layer to be used as ports; therefore >> they must be between 0 and 65,535. The initialization of TID's is >> discussed in the section on initial connection protocol." >> >> " A >> requesting host chooses its source TID as described above, and sends >> its initial request to the known TID 69 decimal (105 octal) on the >> serving host. The response to the request, under normal operation, >> uses a TID chosen by the server as its source TID and the TID chosen >> for the previous message by the requestor as its destination TID. >> The two chosen TID's are then used for the remainder of the transfer." > > Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair. > It works a bit like FTP in that it "hands off" the transfer to the > server port indicated by the server-side TID after the initial request. > If I recall correctly, FTP uses TCP port 20 on one of the ends of the file transfer, so that's the fixed port you can match on if you need to. >> I think a server could choose to continue to use 69 as its TID for the >> full transfer, however in my case it didn't. > > It never will. The first packet is supposed to have a destination TID of > 69 but the rest of the session uses TIDs chosen by each end. > > client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69 > > server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X, > which is where the rest of the transfer stays until a new TID > is selected. > I haven't thought much about it, however I was thinking that the combination of client address and TID would uniquely identify the file transfer, so the server could still use TID 69 if it chose to. However, I missed the bit in the RFC about both ends randomly choosing the TID when I skimmed through it earlier. >> I still remember it today >> because I was only able to get around the unpredictable TID selection >> on both ends by using just host IP addresses, which had some risks >> because it was a very coarse way of selecting "interesting" >> dial-on-demand traffic to hold the link up. > > I'm not sure what you were doing; "using just host IP addresses" doesn't > fix the issue because TFTP still wants to pick TIDs, and the UDP ports > vary when the TIDs do. > The issue was that only certain types of traffic were both allowed to trigger a dial on the dial-on-demand link and to hold it up. Matching on UDP port 69 would bring up the link at the start of the TFTP transfer, however the subsequent TFTP traffic wouldn't match on UDP port 69 of course, so the d-on-d link would be torn down fairly quickly (we had low value tear down timers to reduce cost and contention for dial (ISDN) ports). So the only way I could "identify" the TFTP traffic to keep the call up was to go down a layer, and match on the IP addresses of the known sources/destinations of the TFTP transfer. Of course, that isn't really selective at all, so any traffic to or from those TFTP source/dest addresses would bring up/hold up the d-on-d link. Fortunately the TFTP clients were routers, so traffic directly to them was more controlled and limited than if they had been general purpose hosts. >> So if in Toerless's scenario it is stateless 1:1 translation between >> IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. >> However, if the translation is stateful because translation between >> IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a >> mapping of some form. > > So first let me backtrack - TFTP requires an ALG to work through a NAT > even when the client is on the private side. The return traffic content > needs to be inspected to be able to update the private:public > translation entry. > > I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an > ALG. I can't imagine how to make sense of it safely in a non-1:1 case. > I was thinking that stateless 1:1 translation between IPv4 and IPv6 addresses in the IP headers would work without an TFTP ALG, as long as the UDP Ports/TIDs could be ignored, as there are no IP addresses in the TFTP packets that would need to be translated. 1:1 IPv4 to IPv6 addressing for an Anima network may not be possible to require however, so an ALG for TFTP might be unavoidable. > Note that the whole point of TFTP is to be used on a LAN only. It has > zero security, and it's easily possible that the translation entry could > inadvertently affect some other UDP translation entry. > For many years it was the only way to upload firmware and configuration into a certain vendor's routers, and usually they were remote! Regards, Mark.
68vrrpMIBVRRP MIB (DEPRECATED)[Bob_Hinden][RFC6527]