[Int-area] New I-D on 6a44 (Native IPv6 across NAT44's)

Rémi Després <remi.despres@free.fr> Tue, 08 March 2011 13:53 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205BC3A686C for <int-area@core3.amsl.com>; Tue, 8 Mar 2011 05:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, 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 0QXInPqleR7L for <int-area@core3.amsl.com>; Tue, 8 Mar 2011 05:53:50 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id E64033A63CB for <int-area@ietf.org>; Tue, 8 Mar 2011 05:53:49 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 67F86700008B; Tue, 8 Mar 2011 14:55:04 +0100 (CET)
Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id DFC497000090; Tue, 8 Mar 2011 14:55:03 +0100 (CET)
X-SFR-UUID: 20110308135503916.DFC497000090@msfrf2119.sfr.fr
From: Rémi Després <remi.despres@free.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 08 Mar 2011 14:55:03 +0100
Message-Id: <409D3B95-456B-4EA0-99EB-D8C025C9AAAF@free.fr>
To: Internet Area <int-area@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [Int-area] New I-D on 6a44 (Native IPv6 across NAT44's)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2011 13:53:51 -0000

Hello everybody,

We have submitted tools.ietf.org/html/draft-despres-intarea-6a44-00 and plan to present and discuss it in Prague.
It specifies a lightweight protocol to make Native IPv6 available behind NAT44 CPE's.

Its main difference from the previous 6a44 draft (addressed to Softwire but found out of scope there), is that 6a44 is now viewed and presented as an evolution from Teredo.  

Comments are most welcome. 

Regards,
RD


<<<
Internet Engineering Task Force                          R. Despres, Ed.
Internet-Draft                                                 RD-IPtech
Intended status: Standards Track                            B. Carpenter
Expires: September 8, 2011                             Univ. of Auckland
                                                                 D. Wing
                                                                   Cisco
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                           March 7, 2011


                  Native IPv6 Behind NAT44 CPEs (6a44)
                     draft-despres-intarea-6a44-00

Abstract

   In customer sites having IPv4-only CPEs, Teredo provides a last
   resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081].  However,
   because it is designed to work without involvement of Internet
   service providers, it has significant limitations (connectivity
   between IPv6 native addresses and Teredo addresses is uncertain;
   connectivity between Teredo addresses fails for some combinations of
   NAT types). 6a44 is a complementary solution that, being base on ISP
   cooperation, avoids these limitations.  At the beginning of IPv6
   addresses, it replaces the Teredo well-known prefix by network
   specific prefixes assigned by local ISP's (an evolution similar to
   that from 6to4 to 6rd).  In hosts, 6a44 can be implemented either
   autonomously or as an extension of Teredo.  Except for IANA numbers
   that remain to be confirmed, the specification is intended to be
   complete enough for running codes to be independently written and the
   solution to be incrementally deployed.

...

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Design Goals, Requirements, and Model of Operation . . . . . .  6
     4.1.  Hypotheses about NAT Behavior  . . . . . . . . . . . . . .  6
     4.2.  Last Resort solution for Native IPv6 Connectivity  . . . .  6
     4.3.  Operational Requirements . . . . . . . . . . . . . . . . .  7
     4.4.  Model of Operation . . . . . . . . . . . . . . . . . . . .  8
   5.  6a44 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Specification of Clients and Relays  . . . . . . . . . . . . . 13
     6.1.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  IPv6 Packet Encapsulations . . . . . . . . . . . . . . . . 13
     6.3.  6a44 Bubbles . . . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  Maximum Transmission Units . . . . . . . . . . . . . . . . 15
     6.5.  6a44 Client Specification  . . . . . . . . . . . . . . . . 16
       6.5.1.  Tunnel Maintenance . . . . . . . . . . . . . . . . . . 16
       6.5.2.  Client Transmission  . . . . . . . . . . . . . . . . . 18
       6.5.3.  Client Reception . . . . . . . . . . . . . . . . . . . 20
     6.6.  6a44 Relay Specification . . . . . . . . . . . . . . . . . 22
       6.6.1.  Relay Reception in IPv6  . . . . . . . . . . . . . . . 22
       6.6.2.  Relay Reception in IPv4  . . . . . . . . . . . . . . . 23
     6.7.  Implementation of Automatic Sunset . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 28
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
>>>