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: [email protected]
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:
mon...@7:40pm, wednes...@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
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
