[BEHAVE] Fwd: [nat66] Bar BOF in Stockholm?

[Margaret Wasserman <[e-mail]>]

Just FYI --

If you support the NAT66 work that I presented in this WG several  
months ago and would like to help us determine how to move forward,  
you may be interested in the "bar" BOF I am holding tonight.  See below.

Margaret

> From: Margaret Wasserman <[e-mail]>
> Date: July 29, 2009 6:22:43 AM EDT
> To: Margaret Wasserman <[e-mail]>
> Cc: "[e-mail] Discussion" <[e-mail]>
> Subject: Re: [nat66] Bar BOF in Stockholm?
>
>
>
> 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: [e-mail]
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nat66
>
> _______________________________________________
> nat66 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nat66