This might be of interest for DNSOP, as well. Please follow up as requested
by Mark.
-Peter
----- Forwarded message from Mark Townsley <[EMAIL PROTECTED]> -----
From: Mark Townsley <[EMAIL PROTECTED]>
To: Internet Area <[EMAIL PROTECTED]>, Behave WG <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED]
Cc: IAB <[EMAIL PROTECTED]>, IESG <[EMAIL PROTECTED]>
Subject: [Int-area] IPv4 and IPv6 Co-existence discussions in Dublin
Date: Fri, 18 Jul 2008 18:22:32 +0200
Reply-To: Internet Area <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
X-OriginalArrivalTime: 18 Jul 2008 16:22:56.0857 (UTC)
FILETIME=[899D3490:01C8E8F2]
X-Mailman-Version: 2.1.9
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
Apologies for cross-posting, please reply only to [EMAIL PROTECTED]
All,
Recent discussions in the IETF indicate that the IPv4 and IPv6
co-existence solutions we have available will not be sufficient for all
deployment scenarios which we expect to be necessary in the face of
pressures due to upcoming IPv4 address space exhaustion (or
"completion"). The INT, TSV and OPS ADs would like to discuss with the
community the best way to proceed in chartering this work, with
particular focus on solutions which seem both readily
tractable and for which provide identifiable benefit.
Specifically, two initial steps appear as potential work items:
1. The ability to employ an IPv6-only network infrastructure by, say a
cable or DSL operator, and still be able to serve subscriber networks
that run on IPv4. This scenario was described in the
Vancouver IETF V6OPS meeting [4], and it could be helpful in large networks
where private RFC1918 IPv4 space is not sufficient to address all
devices without resorting to overlays or NAT of the private space
itself. We believe that this is something that can be implemented
through the use of tunneling of IPv4 over IPv6. If the subscribers are
in turn given private IPv4 address space, the tunnels would be connected
to an IPv4 NAT device that serves multiple subscribers, potentially
requiring a device that serves a very large number of translations as
well as tunnels.
It is suggested that this is a work item that fits the SOFTWIRE WG, and
the INT ADs will be sending off a recharter proposal for this WG to
examine this particular problem space and develop a solution accordingly.
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.
We will discuss this design in two places at the upcoming meeting:
BEHAVE and INTAREA (two separate places because we feel it necessary to
involve both the IP experts and people with a history of building
address translators). For the moment, general architectural discussion
should happen on the [EMAIL PROTECTED] list.
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).
- INT, OPS, and TSV ADs
[1] http://www.ietf.org/mail-archive/web/ietf/current/msg48436.html
[2] http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req
[3] http://tools.ietf.org/id/draft-bagnulo-behave-nat64
[4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm
[5] http://tools.ietf.org/id/draft-xli-behave-ivi
_______________________________________________
Int-area mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/int-area
----- End forwarded message -----
--
Peter Koch | | [EMAIL PROTECTED]
DENIC eG | | +49 69 27235-0
Kaiserstraße 75-77 | |
60329 Frankfurt am Main | | http://www.DENIC.DE
-------------------------------------------------------------------------
Eingetr. Nr. 770 im Genossenschaftsregister Amtsgericht Frankfurt am Main
Vorstand: Sabine Dolderer, Marcus Schäfer, Carsten Schiefner, Dr. Jörg Schweiger
Vorsitzender des Aufsichtsrats: Elmar Knipp
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
