Re: [v6ops] new draft: draft-ietf-v6ops-464xlat

MAWATARI Masataka <mawatari@jpix.ad.jp> Tue, 21 February 2012 02:55 UTC

Return-Path: <mawatari@jpix.ad.jp>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5821F856F for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 18:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.01
X-Spam-Level: *
X-Spam-Status: No, score=1.01 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWqbiP-pzmN2 for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 18:55:27 -0800 (PST)
Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3621421F856D for <v6ops@ietf.org>; Mon, 20 Feb 2012 18:55:26 -0800 (PST)
Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 9556FFC021 for <v6ops@ietf.org>; Tue, 21 Feb 2012 11:55:25 +0900 (JST)
Date: Tue, 21 Feb 2012 11:55:27 +0900
From: MAWATARI Masataka <mawatari@jpix.ad.jp>
To: v6ops@ietf.org
In-Reply-To: <4F42ADCC.9070806@bogus.com>
References: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> <4F42ADCC.9070806@bogus.com>
Message-Id: <20120221115526.0320.8FE1F57E@jpix.ad.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.57.03 [ja]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <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, 21 Feb 2012 02:55:33 -0000

Dear all,


I wrote my thoughts.
Basically, there are different requirement and applicable situation
between 4rd and MAP and 464XLAT.

4rd and MAP are stateless solutions due to sharing expanded address
space spliting.
These can solve requirements from ISPs that have much global IPv4
address pool.

464XLAT is stateful solution due to dynamic sharing by session time
spliting.
This can solve requirements from mobile careers that will enlarge
the number of end-users or ISPs that do not have much global IPv4
address pool.  For example, it may be difficult for advancing
countries to enough deploy IPv4/IPv6 dual stack network, I think.

Incidentally, such ISPs I heard from at least in Japan is thinking
they would not like to operate IPv4/IPv6 coexistence techniques on
each their backbone network and would like to operate IPv6-only
access network.  I would like to support them.

As all really know, 464XLAT remove 4rd and MAP, and vice versa, I
also really think.

What I really want to realize is faster deploying IPv6 network and
IPv6 service on the internet.


Kind Regards,
Masataka MAWATARI


* On Mon, 20 Feb 2012 12:32:12 -0800
* Joel jaeggli <joelja@bogus.com> wrote:

> On 2/20/12 04:07 , Vizdal Ale? wrote:
> > +1
> > 
> > I fully agree with Victor's words as this draft is providing a real solution
> > to THE IPv4 exhaustion problem. I do support it and would like to see this 
> > work continued.
> 
> I would probably construe that more narrowly...
> 
> The draft provides a solution to an aspect of a providers ipv4
> exhaustion problem. It appears on the face of it to provide effective
> cover for the deployment of ipv6 only networks which have limited pools
> of available ipv4 addresses.
> 
> > Cheers,
> > Ales
> > 
> >> -----Original Message-----
> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor
> >> Kuarsingh
> >> Sent: Friday, February 17, 2012 1:31 AM
> >> To: fred@cisco.com; v6ops@ietf.org
> >> Cc: draft-ietf-v6ops-464xlat@tools.ietf.org
> >> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat
> >>
> >> Fred,
> >>
> >> This work in my mind represents important work that should continue.
> >> Putting a mobile operator hat on, it provides the last bit of functionally
> >> to make IPv6 with NAT64 a real and workable option for Wireless
> >> deployments based on known behaviours in commercially available product
> >> (I.e. Infrequent, but need for IPv4 connections).
> >>
> >> Given the content in the draft and testing/results provided thus far, it
> >> appears to be a viable option with a number of benefits (especially in the
> >> mobile space related to PCC complacence).
> >>
> >> I would support this work in whichever forum (group) it should exist.
> >>
> >> Regards,
> >>
> >> Victor K
> >>
> >>
> >>
> >> On 12-02-15 9:55 AM, "fred@cisco.com" <fred@cisco.com> wrote:
> >>
> >>>
> >>> A new draft has been posted, at
> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat. Please take a look
> >>> at it and comment.
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> > 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops