[arin-ppml] Mark Townsley: IPv4 and IPv6 Co-existence discussions in Dublin

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Fri Jul 18 13:11:44 EDT 2008

On Fri, Jul 18, 2008 at 04:59:59PM +0000, Paul Vixie wrote:
> for those of you not on the ietf distribution lists, they're talking about
> ipv4 address exhaustion and ipv4/ipv6 coexistence.  see attached.
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

> Apologies for cross-posting, please reply only to int-area at ietf.org
> All,
> Specifically, two initial steps appear as potential work items:
> 2. NAT-PT was deprecated for reasons described in RFC 4966. However,
> there are scenarios where some forms of translation may be necessary. In
> particular, the IAB noted in [1] that scenarios involving servers without
> public IPv4 addresses cannot be adequately handled with the existing
> mechanisms. Requirements on this issue have been discussed in V6OPS, and
> a problem statement document written [2]. One possible translation design
> with reduced scope from NAT-PT as defined in RFC 2766 has been discussed
> recently in the BEHAVE WG [3], but there are other possible designs as
> well [5]. In essence, these designs attempt to reduce the problems present
> in NAT-PT by various techniques, including limiting themselves to a
> simpler part of the overall problem, allowing some changes in IPv6 hosts,
> and generally being designed with a better knowledge of the issues in RFC
> 4966. We believe that, on balance, the benefits outweigh the costs on
> developing a standard method for translation of IPv4 and IPv6. This will
> likely have a smaller scope, at least in the short term, than the original
> NAT-PT though it will inevitably share some of the same limitations.

	being an active user of the code referenced in [5], it meets
	most of my v4/v6 translation requirements (either way)  ... 
	although it does have problems w/ apps that presume the ability
	to tunnel (MMORG et.al. on PS3, WII etc)

	that code has been given to ARIN staff for evaluation/review and
	i'll be talking about it at the I2/JT meetings next week.  Lots
	of interest in some parts of the I2 - EDU community.

	if anyone else wants a copy, hollar.

> We would like to focus our discussions on whether the requirements
> scenario and architectural direction is sufficiently ready so that the
> work can be given to the protocol WGs. If the answer to these questions
> is yes, after the Dublin IETF the ADs will recharter the relevant
> working groups to do the work. V6OPS is already working on the
> requirements. We expect that the behave WG would be the primary solution
> discussion forum and produce the base translation specification. 6MAN
> and DNSEXT would in turn handle any IPv6 stack or DNS protocol impacts
> (including a DNS ALG, if needed).

	IVI doesn't require any DNS specific changes ... (although
	there are some places where there are application specific
	assumptions on IP characteristics... but thats layer violation
	for you.)

> [5] http://tools.ietf.org/id/draft-xli-behave-ivi


More information about the ARIN-PPML mailing list