Re: [v6ops] Comment on siit-dc

Tore Anderson <tore@fud.no> Sun, 26 July 2015 06:30 UTC

Return-Path: <tore@fud.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CDD1A874A for <v6ops@ietfa.amsl.com>; Sat, 25 Jul 2015 23:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nKSqWnNtiUZ for <v6ops@ietfa.amsl.com>; Sat, 25 Jul 2015 23:30:39 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B2C1A874C for <v6ops@ietf.org>; Sat, 25 Jul 2015 23:30:38 -0700 (PDT)
Received: from [2a02:fe0:c412:1fe0::2] (port=41426 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1ZJFS9-0006bY-61; Sun, 26 Jul 2015 08:30:29 +0200
Date: Sun, 26 Jul 2015 08:30:28 +0200
From: Tore Anderson <tore@fud.no>
To: "Fred Baker (fred)" <fred@cisco.com>
Message-ID: <20150726083028.02d6038d@envy.fud.no>
In-Reply-To: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com>
References: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/LRFbAqXelxQahrCrM1cMpau5A_E>
Cc: "draft-ietf-v6ops-siit-dc@tools.ietf.org" <draft-ietf-v6ops-siit-dc@tools.ietf.org>, v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] Comment on siit-dc
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2015 06:30:40 -0000

* Fred Baker (fred)

> The abstract reads:
> 
>    This document describes the use of the Stateless IP/ICMP Translation
>    (SIIT) algorithm in an IPv6 Internet Data Centre (IDC).  In this
>    deployment model, traffic from legacy IPv4-only clients on the
>    Internet is translated to IPv6 when reaches the IDC operator's
>    network infrastructure.  From that point on, it is treated just as if
>    it was traffic from any other IPv6-capable end user.  This
>    facilitates a single-stack IPv6-only network infrastructure, as well
>    as efficient utilisation of public IPv4 addresses.
> 
>    The primary audience is IDC operators who are deploying IPv6, running
>    out of available IPv4 addresses, and/or feel that dual stack causes
>    undesirable operational complexity.
> 
> I see what you're saying, but can read it as specifying how an RFC
> 6052 address might be used, when you're specifying the use of
> siit-eam. May I suggest tweaking the abstract to clarify that?

Point taken. How about:

    This document describes the use of the Stateless IP/ICMP Translation
    (SIIT) algorithm in an IPv6 Internet Data Centre (IDC).  In this
    deployment model, traffic from legacy IPv4-only clients on the
    Internet is translated to IPv6 when reaches the IDC operator's
    network infrastructure.  From that point on, it is treated just as if
    it was traffic from any other IPv6-capable end user. The IPv6
    endpoints may be numbered using arbitrary (non-IPv4-translatable)
    IPv6 addresses. This facilitates a single-stack IPv6-only network
    infrastructure, as well as efficient utilisation of public IPv4
    addresses.

    The primary audience is IDC operators who are deploying IPv6,
    running out of available IPv4 addresses, and/or feel that dual
    stack causes undesirable operational complexity.

...?

Tore