IETF Logo Mail Archive

Re: [v6ops] [BEHAVE] protocols without need for ALG ?

"ietfdbh" <ietfdbh@comcast.net> Tue, 04 August 2015 21:58 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6E1ACF08 for <v6ops@ietfa.amsl.com>; Tue, 4 Aug 2015 14:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.01
X-Spam-Level:
X-Spam-Status: No, score=-1.01 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, 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 IOkfUCQnw--s for <v6ops@ietfa.amsl.com>; Tue, 4 Aug 2015 14:58:22 -0700 (PDT)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4131ACF16 for <v6ops@ietf.org>; Tue, 4 Aug 2015 14:58:19 -0700 (PDT)
Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-05v.sys.comcast.net with comcast id 0lxx1r00D4tLnxL01lyKwl; Tue, 04 Aug 2015 21:58:19 +0000
Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-02v.sys.comcast.net with comcast id 0lyJ1r00B2yZEBF01lyJLG; Tue, 04 Aug 2015 21:58:19 +0000
From: ietfdbh <ietfdbh@comcast.net>
To: 'Toerless Eckert' <eckert@cisco.com>, v6ops@ietf.org, behave@ietf.org
References: <20150730205806.GI1667@cisco.com>
In-Reply-To: <20150730205806.GI1667@cisco.com>
Date: Tue, 04 Aug 2015 17:58:17 -0400
Message-ID: <006d01d0cf00$ac05b830$04112890$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJOIOzxA//lU3Ej5GL/YVhvfDRm9p0Bvn7A
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1438725499; bh=Hum09xIitN2sp1vBiPjV/9XECw4jqMZOSXH/TMxJ2KQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=nvUAKd0CMH51ezG6mSMKXJWn/U30YviPVeMan51+U+h661RAI2E+kGY1IXZ46Co3n DOpkSsMaR/cJvqYb3OIPFkagvk9d5Whqj8lQZtPcqlqpTURCxe2KcRQ7O8CgSw2UK0 W7Q3lFvK8EnKWtHeHDN/IkJC5b47QWNVZFIY38unmRgFLqyUiOvMn/DHm8Rr5akn3/ C1CVi5XthMT9QP1q3TNB0FmpjLR3QyvCCRSjAqKynJGIlezOJpO0eX24cQJnJC7Jhm EZsGza9Ls8I0PSXTH/5FDxdu7Qv1yVrHjiCmBL+Gfq4nJA6sq2DgVM8IjwL47OpRNi JiU2jjyQqcw1A==
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/se6VL9p2lshotkUUWveVwuciDDU>
X-Mailman-Approved-At: Thu, 06 Aug 2015 10:46:16 -0700
Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 21:58:23 -0000

RFC2962 includes a detailed description of the requirements and
   limitations for an implementation of an SNMP Application Level
   Gateway.  It also discusses other approaches to exchange SNMP packets
   across conflicting addressing realms.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Toerless
> Eckert
> Sent: Thursday, July 30, 2015 4:58 PM
> To: v6ops@ietf.org; behave@ietf.org
> Subject: [BEHAVE] protocols without need for ALG ?
> 
> 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
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

v2.23.0 | Report a Bug | By Email