[v4tov6transition] 6a44 updated version (draft-despres-softwire-6a44-01)

Rémi Després <remi.despres@free.fr> Tue, 12 October 2010 14:22 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5193A695A; Tue, 12 Oct 2010 07:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG461dbLMYl1; Tue, 12 Oct 2010 07:22:49 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 3FA103A6823; Tue, 12 Oct 2010 07:22:49 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 580D97000092; Tue, 12 Oct 2010 16:24:03 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 10D427000091; Tue, 12 Oct 2010 16:24:02 +0200 (CEST)
X-SFR-UUID: 20101012142403690.10D427000091@msfrf2402.sfr.fr
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Oct 2010 16:24:02 +0200
Message-Id: <33C03659-46D2-4845-A41E-892B1EB75195@free.fr>
To: Softwires <softwires@ietf.org>, v4tov6transition <v4tov6transition@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [v4tov6transition] 6a44 updated version (draft-despres-softwire-6a44-01)
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2010 14:22:50 -0000

Hi all,

Version -01 of the 6a44 draft has just been posted (www.ietf.org/id/draft-despres-softwire-6a44-01.txt)

It includes correction of a substantial bug in Figure 3, an some clarifications.
Thanks to all those who helped to improve it.

Regards,
RD







-----------------------------------------------------------------------
Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Standards Track                            B. Carpenter
Expires: April 15, 2011                                Univ. of Auckland
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                        October 12, 2010


                  Native IPv6 Across NAT44 CPEs (6a44)
                     draft-despres-softwire-6a44-01

Abstract

   Most CPEs should soon be dual stack, but a large installed base of
   IPv4-only CPEs is likely to remain for several years.  Also, with the
   IPv4 address shortage, more and more ISPs will assign private IPv4
   addresses to their customers.  The need for IPv6 connectivity
   therefore concerns hosts behind IPv4-only CPEs, including such CPEs
   that are assigned private addresses.  The 6a44 mechanism specified in
   this document addresses this need, without limitations and
   operational complexities of Tunnel Brokers and Teredo to do the same.

   6a44 is based on an address mapping and on a mechanism whereby
   suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via
   a stateless 6a44 server function operated by their Internet Service
   Provider.  With it, IPv6 traffic between two 6a44 hosts in a single
   site remains within the site.  Except for IANA numbers that remain to
   be assigned, the specification is intended to be complete enough for
   running codes to be independently written and interwork.

...

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  6a44 IPv6 Address Format . . . . . . . . . . . . . . . . . . .  6
   4.  Address Mappings and Encapsulations  . . . . . . . . . . . . .  8
   5.  MTU considerations . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Host Acquisition of IPv6 Addresses and their Lifetimes . . . . 10
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

------------------------------------------------------------------------


















Despres, et al.          Expires April 15, 2011                 [page 2]