Re: [nat66] Bar BOF in Stockholm?
Margaret Wasserman <mrw@sandstorm.net> Wed, 29 July 2009 10:22 UTC
Return-Path: <mrw@sandstorm.net>
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 26F213A68B3 for <nat66@core3.amsl.com>; Wed, 29 Jul 2009 03:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.83
X-Spam-Level:
X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MLH_Stock1=0.87]
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 tET+ZjOS34tA for <nat66@core3.amsl.com>; Wed, 29 Jul 2009 03:22:47 -0700 (PDT)
Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 095DD3A6A24 for <nat66@ietf.org>; Wed, 29 Jul 2009 03:22:46 -0700 (PDT)
Received: from dhcp-53f4.meeting.ietf.org (dhcp-53f4.meeting.ietf.org [130.129.83.244] (may be forged)) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n6TAMile001260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2009 06:22:45 -0400 (EDT) (envelope-from mrw@sandstorm.net)
Message-Id: <C3F98C1F-E47D-41BD-B5EF-770826968BC0@sandstorm.net>
From: Margaret Wasserman <mrw@sandstorm.net>
To: Margaret Wasserman <mrw@sandstorm.net>
In-Reply-To: <032F47AF-2ED2-4487-8524-9F5D9EE18339@sandstorm.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 29 Jul 2009 06:22:43 -0400
References: <032F47AF-2ED2-4487-8524-9F5D9EE18339@sandstorm.net>
X-Mailer: Apple Mail (2.935.3)
Cc: "nat66@ietf.org Discussion" <nat66@ietf.org>
Subject: Re: [nat66] Bar BOF in Stockholm?
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: Wed, 29 Jul 2009 10:22:48 -0000
This "Bar" BOF will be held in room 501. It will start ~5 minutes after the end of the plenary (~7:30pm) and will last for about an hour. I don't think that we will have a projector, and I'm not planning for any presentations. Our strawman agenda (subject to change this evening) is: - Review status of NAT66 document (Margaret, 10 min) Improvements needed: - Extend mechanism to prefixes longer than /48 - More clarity on issues with checksum correction in transport layers - Editorial improvements - Quick Reminder about Dave Thaler's SAF Presentation (Margaret, 5 min) - How can we move ahead? (Discussion, 45 min) I have attached a strawman charter for a WG to do this work that we can discuss if that makes sense. Or, perhaps we'll decide that there is a better way to move forward than having an IETF WG? Margaret Network Address Translation for IPv6 (NAT66) Last Modified: July 29, 2008 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing Lists: General Discussion: nat66@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nat66 Archive: http://www.ietf.org/mail-archive/web/nat66 Description of the Working Group: Due to its vastly explanded address space and allocation policies that result in a large number of addresses being assigned to each enterprise or residential site, IPv6 eliminates one of the primary reasons for using a Network Address Translator (NAT), the amplification of limited address space. Many of the other reasons for using NAT can be better addressed using less damaging mechanism, as described in RFC 4864, Local Network Protection for IPv6. However, IPv6 does not fully address one of the primary reasons for NAT use in enterprise networks, address independence. In this context, address independence refers to the use of internal enterprise addresses with the following properties: o The IPv6 addresses in use inside the local network (for nodes, ACLs, logs) do not need to be renumbered if the ISP changes a site's external address prefix. o The IPv6 addresses in use inside the local network (for nodes, ACLs, logs) do not need to be renumbered when a site changes ISPs. o It is not necessary for an administrator to convince an ISP to route his or her internal IPv6 addresses. This address independence requirement has been a primary driver for IPv4 NAT deployment in medium to large-sized enterprise networks, including NAT deployments in enterprises that have plenty of IPv4 provider-independent address space (from IPv4 "swamp space"). As explained in draft-carpenter-renum-needs-work-03.txt, we have not fully eliminated the cost and complexity of renumbering in IPv6, so the need for address independence is still driving demand for NAT in enterprise IPv6 deployments. There are many well-understood problems caused by NAT deployment, many of which relate to specific properties of IPv4 NAT devices including: maintaining per-connections state in middleboxes, port mapping and transport header modification for checksum correction. These properties cause brittleness in the network, constrain innovation at the transport layer, and interfere with security mechanisms that encrypt the entire IP payload. It should be possible to avoid these issues with a carefully designed IPv6 NAT mechanism. The NAT66 WG is chartered to document a NAT mechanism for IPv6 that will avoid many of the problems caused by IPv4 NAT, while retaining the address independence property that is needed for some enterprise deployments. This work will be based on draft-behave-mrw-nat66-2.txt. Any form of address or prefix translation, including NAT66, involves the modification of IP addresses in the network, causing a loss of end-to-end transparency. The problems with modifying IP addresses in the network are described in the IAB Considerations for UNIlateral Self-Address Fixing (UNSAF) document, RFC 3424. In this document, the IAB suggests that all mechanisms that translate addresses in the networks should include an exit strategy/transition plan that will restore end-to-end transparency. In order to provide an exit strategy for those who need one, the NAT66 WG will also develop a mechanism for Self-Address Finding (SAF) to restore end-to-end transparency. Milestones: Sep 2009: Charter WG Nov 2009: NAT66 draft becomes a WG item Mar 2010: SAF draft beomes a WG item Apr 2010: NAT66 draft sent to IESG for publication as PS Aug 2010: SAF draft sent to IESG for publication as PS On Jul 23, 2009, at 12:23 PM, Margaret Wasserman wrote: > > Do you support the refinement and publication of the NAT66 work? If > so, would you be interested in holding a bar BOF in Stockholm to > figure out how best to proceed towards that goal? Perhaps on Monday > evening (at 7:40pm) or Wednesday evening (7:30pm)? > > If you would like to attend, please reply to me (preferably not the > whole list) and let me know which time(s) will work for you: > Monday@7:40pm, Wednesday@7:30pm, or both. I will attempt to > schedule something for the time that most folks can attend, and I'll > send the details back to the list. > > Margaret > > > _______________________________________________ > nat66 mailing list > nat66@ietf.org > https://www.ietf.org/mailman/listinfo/nat66
- [nat66] Bar BOF in Stockholm? Margaret Wasserman
- Re: [nat66] Bar BOF in Stockholm? Margaret Wasserman
- Re: [nat66] Bar BOF in Stockholm? Margaret Wasserman
- Re: [nat66] Bar BOF in Stockholm? Margaret Wasserman