Re: [nat66] Comments on draft-mrw-nat66-12

Fred Baker <fred@cisco.com> Tue, 15 March 2011 23:36 UTC

Return-Path: <fred@cisco.com>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFAF3A6ECA for <nat66@core3.amsl.com>; Tue, 15 Mar 2011 16:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.396
X-Spam-Level:
X-Spam-Status: No, score=-110.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4zEt5Dsl8Aw for <nat66@core3.amsl.com>; Tue, 15 Mar 2011 16:36:03 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6BDB73A6D46 for <nat66@ietf.org>; Tue, 15 Mar 2011 16:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2115; q=dns/txt; s=iport; t=1300232249; x=1301441849; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=qyurosXvbwCwYExdpElbu8XXgaOB4Wu4PLcrgMPNA0I=; b=ZjtuAm/evnakFDArYfN5+4c3T/eKzQnlY5bOkDy/iJCaZOV/T/2v/OWQ DdcVprsrCbUHoKUd7bByNKAxIoIcNN9CfePJatNjjcObfZwbP4ATvMxKz s1taOOlKcdHSIhoU/ugXskRm/NwlRAqmVSYD1c+4QMzx/9xIfNzb2Gj3B s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEADaVf02tJV2c/2dsb2JhbACmDnekTZxthWIEhTCHLYNP
X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="347458305"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 23:37:28 +0000
Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FNbNnI003684; Tue, 15 Mar 2011 23:37:28 GMT
Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 15 Mar 2011 16:37:28 -0700
X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 15 Mar 2011 16:37:28 -0700
Mime-Version: 1.0 (Apple Message framework v1082)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <5E3E1015-9750-4ADA-91D9-F10FFFDB2BD0@apple.com>
Date: Tue, 15 Mar 2011 16:37:12 -0700
Message-Id: <B4FD874E-1AC2-49DF-A7C0-D1D48B940292@cisco.com>
References: <20110314063002.28048.29694.idtracker@localhost> <19F3A4CD-F39C-4F17-A6E9-7AA8AFBC6B3B@cisco.com> <CF8367A6-F303-43D7-99C6-D40D1DD5D5D9@free.fr> <125BC580-ED43-40EE-B6B9-FD88557C35B9@apple.com> <758DD037-9DC2-4A1E-BEAE-7E99CBED6D3A@cisco.com> <5E3E1015-9750-4ADA-91D9-F10FFFDB2BD0@apple.com>
To: james woodyatt <jhw@apple.com>
X-Mailer: Apple Mail (2.1082)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: NAT66 HappyFunBall <nat66@ietf.org>
Subject: Re: [nat66] Comments on draft-mrw-nat66-12
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2011 23:36:04 -0000

On Mar 15, 2011, at 4:12 PM, james woodyatt wrote:

> On Mar 15, 2011, at 15:51 , Fred Baker wrote:
>> 
>> To my mind, section 5 spends quite a bit of effort indicating that there are issues around differences in addresses.
> 
> It does, but I think there might be room to improve section 2.4 further by discussing the problem of choosing the correct valid and preferred lifetimes for routers advertising the internal network prefix.  There may also be ramifications for firewalls that implement I-D.ietf-pcp-base.

In RIPng, IS-IS, OSPFv3, and BGP-4+, route lifetimes are not a question of attributes of the prefix such as whether it is internal or external. They are attributes specified in the routing protocol. In any variant of RIP, the system originating the prefix does so if and only if the relevant interface is up, and does so as often as the announcement timer fires - by default, in RIPng, every 30 seconds. In OSPF, a prefix LSA similarly reflects the prefix's state as seen by its originator, is refreshed every 1800 seconds as long as the prefix remains up, and is withdrawn should it go down. IS-IS follows suit, and so does BGP4+. 


To my mind, the ramifications for the port control protocol are very simple. 

AN NPTv6 TRANSLATOR DOES NOT, EVER, UNDER ANY CIRCUMSTANCES, SCREW WITH PORTS. COLD STOP, NOTHING MORE TO SAY, AND THE DRAFT SPENDS A FAIR BIT OF SPACE SAYING THAT INCLUDING THE WORDS "MUST NOT".

If a firewall, such as specified in RFC 6092, is opening or closing port filters, that is something the filter logic and its manager do. The firewall might be configured to open these ports, close those ports, and close a third set of ports unless someone asks for them to be opened. The PCP conversation is with the firewall functionality, which is COMPLETELY AND 100% SEPARATE FROM THE NPTv6 TRANSLATOR FUNCTIONALITY.

Hence, I have no clue what you're getting at in asking me to wax eloquent on in either topic, and mystified as to why you would want me to. It's irrelevant to NPTv6.