Subject: [v6ops] Fw: I-D Action: draft-anderson-v6ops-siit-eam-00.txt

From: Tore Anderson <[email-masked]>
Date: Fri, 21 Nov 2014 14:12:46 +0100

Hello WG,

This draft is an attempt to work in Dave Thaler's comments directed at
SIIT-DC during the v6ops session, namely that «this isn't a new
protocol, just good use cases» (quote from the published minutes).

The missing piece from the existing set of protocols is the ability to
provide static IPv4,IPv6 mappings that override RFC6052. Currently, I
cannot go to a router vendor and ask for an "implementation of RFC X"
that can be used for SIIT-DC:

- RFC 6144 doesn't suffice, as it does not specify any protocols, and
  as such cannot be implemented per se.
- RFC 6145 doesn't suffice, as it mandates that a stateless translator
  must use the RFC6052 algorithm for all address translations (except
  ICMPv6->ICMPv4, through the update in RFC6791)
- RFC 6146 doesn't suffice, because it brings with it a lot of unwanted
  stateful stuff (Session Tables and Binding Information Bases, for
  example)

This document attempts to remedy this shortcoming by updating SIIT
(RFC6145) directly, adding the static mapping functionality. This way,
I can take the SIIT-DC documents off the standards track, and focus on
describing the particular data centre use case, without specifying any
new protocols.

The draft also attempts to clarify the rationale for the static
mappings, also requested by Dave Thaler, by including a "Problem
Statement" section. It also includes a section noting that the
translations are not checksum neutral, as pointed out by Andrew
Yourtchenko.

I have renamed "Static Mapping" to "Explicit Address Mapping", because
1) it occurred to me that a mapping can be learned dynamically (e.g.,
from DNS), and the resulting "Dynamic Static Mapping" does sound
rather confusing, and
2) the inclusion of "Address" better communicates that this is only
used for (layer 3) addresses, not (layer 4) ports and such.

As an added bonus, the question of naming of SIIT-DC goes away. With
this update, there is no new protocol in the data centre drafts,
therefore they are simply using plain "SIIT".

Finally, another reason for separating the protocol update from the
data centre use case, is that other use cases may then proceed to use
this algorithm. I have identified that 464XLAT's CLAT component in some
cases might do so already, and have documented this in the appendix.

I would very much appreciate the WG's input on whether or not this is a
better way to proceed than to keep the normative language in the
SIIT-DC documents and keep them on the standards track.

Tore

Start videresendt melding:

Dato: Fri, 21 Nov 2014 04:55:30 -0800
Fra: [email-masked]
Til: [email-masked]
Nyhetsgruppe: gmane.ietf.announce
Emne: I-D Action: draft-anderson-v6ops-siit-eam-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Explicit Address Mappings for Stateless
        IP/ICMP Translation Author          : Tore Anderson
	Filename        : draft-anderson-v6ops-siit-eam-00.txt
	Pages           : 8
	Date            : 2014-11-21

Abstract:
   This document extends the Stateless IP/ICMP Translation Algorithm
   (SIIT) with an Explicit Address Mapping algorithm.  This algorithm
   facilitates stateless IP/ICMP translation between arbitrary (non-
   IPv4-translatable) IPv6 endpoints and IPv4.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-eam/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam-00

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2014 08:19:56 +1300

Hi,

I think this is a good way to handle the issue and I can't
actually find any technical comments on the draft - nice job!

Just one nit, it lacks an Updates: 6145 (if approved) header.

   Brian

On 22/11/2014 02:12, Tore Anderson wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ca By <[email-masked]>
Date: Thu, 27 Nov 2014 05:41:49 -0800

> Just one nit, it lacks an Updates: 6145 (if approved) header.
I have read draft-anderson-v6ops-siit-eam-00

I agree with Brian, this document is well written and useful to the
community.  It should be adopted by the working group.

This document fills a very relevant gap where the solution in RFC6052 is
too strict and does not meet the need of the network operator who is
working with limited IPv4 space.

As a practical matter, this solution is already in place (running code) and
this document does a good job of summarizing those lessons's learned to
standardize implementations and educate the community.

Regards,

Cameron