[v6ops] New I-D on 4rd
Rémi Després <remi.despres@free.fr> Tue, 08 March 2011 11:05 UTC
Return-Path: <remi.despres@free.fr>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F6E3A67DA; Tue, 8 Mar 2011 03:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.192
X-Spam-Level:
X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.757, 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 mNbIFF+0v0n1; Tue, 8 Mar 2011 03:05:21 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 556AE3A6834; Tue, 8 Mar 2011 03:05:21 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 060517000082; Tue, 8 Mar 2011 12:06:35 +0100 (CET)
Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 70B5E700008D; Tue, 8 Mar 2011 12:06:32 +0100 (CET)
X-SFR-UUID: 20110308110634461.70B5E700008D@msfrf2216.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 12:06:31 +0100
Message-Id: <9D784E45-EC2C-4D11-8D92-1F5380CEA692@free.fr>
To: Internet Area <int-area@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Cc: v6ops <v6ops@ietf.org>
Subject: [v6ops] New I-D on 4rd
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 08 Mar 2011 11:05:22 -0000
Hello everybody, We have submitted tools.ietf.org/html/draft-despres-intarea-4rd-00 and plan to present it and discuss it in Prague. It specifies the 4rd architecture and protocol for IPv4 Residual Deployment across IPv6 (4rd). It is an update from the previous proposal addressed to Softwire for IETF 79, but concluded there to be out of scope. Two other recent drafts refer to the 4rd specification: - tools.ietf.org/id/draft-matsushima-v6ops-transition-experience-00 - tools.ietf.org/id/draft-sun-intarea-4rd-applicability-00.txt Comments are most welcome. Regards, RD <<< Internet Engineering Task Force R. Despres, Ed. Internet-Draft RD-IPtech Intended status: Standards Track S. Matsushima Expires: September 8, 2011 SoftBank T. Murakami IP Infusion O. Troan Cisco March 7, 2011 IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional draft-despres-intarea-4rd-00 Abstract This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network infrastructure. During the long transition period from IPv4-only to IPv6-only, a service provider's network infrastructure will have to deploy IPv6. But it will also have to maintain some IPv4 connectivity for a number of customers, for both outgoing and incoming connections, and for both customer-individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4. ... Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. From an IPv6 Prefix to a 4rd Prefix . . . . . . . . . . . 5 4.2. From a 4rd Prefix longer than 32 bits to a Port-set ID . . 6 4.3. From a Port-Set ID to a Port Set . . . . . . . . . . . . . 6 4.4. From an IPv4 Address or IPv4 address + Port to a CE IPv6 address . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. MTU Considerations . . . . . . . . . . . . . . . . . . . . 9 5. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 9 6. BR and CE behaviors . . . . . . . . . . . . . . . . . . . . . 10 6.1. Encapsulation and IPv6 Fragmentations . . . . . . . . . . 10 6.2. Domains having only One Mapping rule . . . . . . . . . . . 11 6.2.1. BR reception of an IPv4 packet . . . . . . . . . . . . 11 6.2.2. BR reception of an IPv4/IPv6 packet . . . . . . . . . 12 6.2.3. CE reception of an IPv4 packet . . . . . . . . . . . . 12 6.2.4. CE reception of an IPv4/IPv6 packet . . . . . . . . . 13 6.3. Domains having Multiple Mapping Rules (TBD) . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 >>>
- [v6ops] New I-D on 4rd Rémi Després