Re: [BEHAVE] Comments on the NAT66 draft
Margaret Wasserman <mrw@lilacglade.org> Thu, 06 November 2008 20:40 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01C23A6AAA for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 6 Nov 2008 12:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.067
X-Spam-Level:
X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-1.564, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
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 TnstrmP5AGoS for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 6 Nov 2008 12:40:28 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 755CB3A696C for <v6ops-archive@lists.ietf.org>; Thu, 6 Nov 2008 12:40:28 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KyBdL-0002T0-At for v6ops-data@psg.com; Thu, 06 Nov 2008 20:39:15 +0000
Received: from [69.33.111.75] (helo=sirocco.sandstorm.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <mrw@lilacglade.org>) id 1KyBdD-0002SF-FW for v6ops@ops.ietf.org; Thu, 06 Nov 2008 20:39:11 +0000
Received: from [10.2.0.63] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id mA6Kc2j6030333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2008 15:38:05 -0500 (EST) (envelope-from mrw@lilacglade.org)
Cc: IPv6 Operations <v6ops@ops.ietf.org>, Behave WG <behave@ietf.org>
Message-Id: <4ECF9F45-314E-4877-BB75-6D9EAB87B970@lilacglade.org>
From: Margaret Wasserman <mrw@lilacglade.org>
To: Wes Beebee <wbeebee@cisco.com>
In-Reply-To: <BB56240F3A190F469C52A57138047A03014762B5@xmb-rtp-211.amer.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: [BEHAVE] Comments on the NAT66 draft
Date: Thu, 06 Nov 2008 15:38:02 -0500
References: <4911B9E7.8090108@free.fr> <BB56240F3A190F469C52A57138047A03014762B5@xmb-rtp-211.amer.cisco.com>
X-Mailer: Apple Mail (2.929.2)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
Hi Wes, Hosting this discussion on the behave WG mailing list is certainly not an attempt to avoid folks in v6ops having feedback on the work, it is just that behave seems like the right place to work on the actual specification. With all of the v4v6 translation discussion happening in behave, I think we've been hoping that the v6 folks will show up in behave and have this discussion, and do this work, there. I'm sure that the v6ops chairs are aware of this work -- my co-author Fred Baker is one of them. If they think that it would be useful to discuss NAT66 in v6ops, I'd certainly be happy to come to the v6ops meeting and talk about it. Personally, though, I'd rather that we discuss this in one forum (behave) and that interested people bring their thoughts, opinions and feedback to that forum. Margaret On Nov 5, 2008, at 11:31 AM, Wes Beebee (wbeebee) wrote: > I understand that NAT66 work on the details is being done in the > BEHAVE Working Group - but shouldn't we also include a discussion at > v6ops on whether NAT66 should be standardized? After all, they're > more privy to the discussions that created the Local Network > Protection RFC... > > - Wes > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Rémi Després > Sent: Wednesday, November 05, 2008 10:21 AM > To: Margaret Wasserman > Cc: Behave WG > Subject: [BEHAVE] Comments on the NAT66 draft > > Hi Margaret, > > Sorry for so late an answer (I was too busy preparing my own draft > before the deadline). > Here are my comments, section per section. > > Sec. 3 - Motivation) > a. I _FULLY SUPPORT_ that IETF should standardize some ways to keep, > in IPv6, appreciated benefits of NAT44s (and to avoid as much as > possible their drawbacks). > b. In your list of NAT44 appreciated services (i.e. provider > independent addressing, simplified site multihoming, topology > hiding), "host privacy" should IMHO be added. This is the > impossibility, from the outside, to see that several consecutive > connections were initiated by the same host. > c. Concerning multihoming, a more detailed analysis of what NATs do, > and don't do, would be a useful clarification. (In particular, they > are incompatible with multihoming of both Shim6 and SCTP. These the > protocols, to take advantage of multihoming, exchange address > information in payloads, protected by strong checksums.) > > Sec. 4 - NAT66 overview > a. Since your proposed mechanism is only based on stateless and > reversible _mappings_, calling it a NAT leads, IMHO, to confusion: > NATs are generally understood, and used, as NAPTs. They do stateful > and non-reversible 1:n _translations_. > b. With a different name than NAT for such a proposal, IETF could > advertise that it _does not endorse NATs in IPv6_. This would IMHO > increase (or restore?) confidence in IPv6. "Mapping" instead of > "translation"would be a logical word in such a name. > > Sec. 5 - NAT66 Address Mapping Mechanisms > - Topology hiding is in fact possible without losing reversibility > of the mapping. Cf the comment on 5.1.2. > > Sec. 5.1 - Checksum-Neutral Mapping > - IMHO, it would be useful to make it clear in this section (like in > the introduction) that the proposed mapping does not apply to > addresses that are transmitted in payloads. ALGs could be be added > to convert addresses in TCP payloads TCP, as it is done in some > NAT44s. But it cannot be done not in SCTP payloads because of the > stronger checksum algorithm. > > Sec. 5.1.1 - Two-way Algorithmic Address Mapping > - The proposed limitation to /48 internal and external prefixes is > stronger than necessary. > - A sufficient limitation is that external prefixes are not longer > than internal ones. (If the external prefix is shorter, a few 0 > bits can be added to it, up to the length to the internal one.) For > example a /56 external with a /60 internal should be permitted. > > Sec. 5.1.2 - Topology hiding Option > - For outgoing UDP and TCP connections, it is in fact possible to > hide the internal topology without losing reversibility of the > mapping: the algorithmic mapping is, for this, applied jointly to > the subnet identifier AND to port bits (excluding port-bits 0 and 1 > that must remain constant in dynamic ports). UDP and TCP checksums > are then incrementally adjusted (like IP checksums). > - In addition to topology hiding, this mechanism provides _host > privacy_ , as defined in the comment on sec. 3 :-) . > > Sec 6. - Prefixes for Port Mapping > - I don't see the need for this section in this document. The > mapping applies to internal and external prefixes, independently of > how they can be configured. > > Sec 7 - A note on Port Mapping > - Agreed: address amplification should not be needed in IPv6. Agreed > also: some transport layers that encrypt data are incompatible with > port mapping. But this is not sufficient to abandon port mapping all- > over. (See the comment on 5.1.2.) > > Sec 8 - Security Considerations > - In TCP, DCCP, SCTP, packets that initiate connection > establishments can be individually recognized (SYN without ack in > the case of TCP). Incoming connections can therefore be blocked > with stateless operation, but this is not the case for UDP (per- > connection stateful operation is needed). Whether blocking UDP > incoming connections is worth it, in global to local IPv6 gateways, > is therefore uncertain (hosts must anyway have their own blocking > of undesirable incoming connections). > > In summary: > - the document introduces IMO a *very useful subject*. > - Before freezing any recommendation, its relationship with other > layers, in particular with other stateless address mappings, should > be further studied. > > Best regards, > > RD > > > Margaret Wasserman (1-12/1-31/200x) 10/27/08 7:59 PM: >> I have posted a NAT66 draft, so that we can have a better-grounded >> discussion of whether it makes sense to include NAT66 as a work >> item in the behave charter. The draft can be found at the >> following URL: >> >> http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt >> >> Feedback would be greatly appreciated!
- RE: Comments on the NAT66 draft Wes Beebee (wbeebee)
- RE: [BEHAVE] Comments on the NAT66 draft Wes Beebee (wbeebee)
- Re: Comments on the NAT66 draft EricLKlein
- Re: [BEHAVE] Comments on the NAT66 draft Iljitsch van Beijnum
- RE: [BEHAVE] Comments on the NAT66 draft Wes Beebee (wbeebee)
- Re: Comments on the NAT66 draft Rémi Després
- Re: [BEHAVE] Comments on the NAT66 draft Brian E Carpenter
- Re: [BEHAVE] Comments on the NAT66 draft Margaret Wasserman
- Re: [BEHAVE] Comments on the NAT66 draft Rémi Després
- Re: [BEHAVE] Comments on the NAT66 draft Rémi Després
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft Gert Doering
- Re: Comments on the NAT66 draft Rémi Denis-Courmont
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft Gert Doering
- Re: [BEHAVE] Comments on the NAT66 draft Rémi Després
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft Iljitsch van Beijnum
- Re: Comments on the NAT66 draft EricLKlein
- RE: Comments on the NAT66 draft Gunter Van de Velde (gvandeve)
- Re: Comments on the NAT66 draft Tim Chown
- Re: Comments on the NAT66 draft Margaret Wasserman
- Re: Comments on the NAT66 draft Gert Doering
- Re: Comments on the NAT66 draft Gert Doering
- Re: Comments on the NAT66 draft Gert Doering
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft EricLKlein
- Re: Comments on the NAT66 draft Gert Doering
- Re: [BEHAVE] Comments on the NAT66 draft Rémi Després
- Re: Comments on the NAT66 draft james woodyatt
- Re: Comments on the NAT66 draft Gert Doering
- Re: Comments on the NAT66 draft ericlklein
- Re: Comments on the NAT66 draft Gert Doering
- The renumbering problem [Re: [BEHAVE] Comments on… Brian E Carpenter
- Re: The renumbering problem [Re: [BEHAVE] Comment… james woodyatt
- Re: The renumbering problem [Re: [BEHAVE] Comment… Gert Doering
- Re: The renumbering problem [Re: [BEHAVE] Comment… james woodyatt
- Re: The renumbering problem [Re: [BEHAVE] Comment… Gert Doering
- Re: The renumbering problem [Re: [BEHAVE] Comment… james woodyatt
- Re: [BEHAVE] The renumbering problem [Re: Comment… Iljitsch van Beijnum