Re: [v6ops] Fwd: 464XLAT Trial Deployment Report

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 03 February 2012 23:18 UTC

Return-Path: <sarikaya2012@gmail.com>
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 E359B21F84B5 for <v6ops@ietfa.amsl.com>; Fri, 3 Feb 2012 15:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.49
X-Spam-Level:
X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 zdpPlqQCQkKB for <v6ops@ietfa.amsl.com>; Fri, 3 Feb 2012 15:18:01 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5383721F85D8 for <v6ops@ietf.org>; Fri, 3 Feb 2012 15:18:01 -0800 (PST)
Received: by yhkk25 with SMTP id k25so2156023yhk.31 for <v6ops@ietf.org>; Fri, 03 Feb 2012 15:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=i2D0xaJ3Ou3dNJDMnBGQ6d45acFKTLdWWGH2mUfJh7M=; b=G/Ekyf7A67K6b810H4usvqTOA9YQeSw4l25L8gZZ8IZCSiWutZPFlj6aAbgN2qb+dX Vy1OkLcSMBfQwaT3jqHUqEkv8R1BkVPSIdb7PdFaN2QwXLHXyg/G8Po1rsXdf7jW1oPn zW+26dOOJFBFUv6EaPq+AXlWdxWH4uVF49tTg=
MIME-Version: 1.0
Received: by 10.236.184.226 with SMTP id s62mr14123437yhm.104.1328311080878; Fri, 03 Feb 2012 15:18:00 -0800 (PST)
Received: by 10.236.108.165 with HTTP; Fri, 3 Feb 2012 15:18:00 -0800 (PST)
In-Reply-To: <CAD6AjGQ8JJWcYab6dfjc=qZsx5xEjgcLS=MjYd9QUDz=Rr3GPg@mail.gmail.com>
References: <CAD6AjGSRUdx32arseR26RzHNtMri8Vrif3dCQmuk7B52GmoHAw@mail.gmail.com> <FBD9BBC7-A537-4ABE-ABEB-76098F1BB415@cisco.com> <CAC8QAceBw=jBaJOXVUthBYmF256_0uU7HtYsfe7VcxodLbesPQ@mail.gmail.com> <CAD6AjGQ8JJWcYab6dfjc=qZsx5xEjgcLS=MjYd9QUDz=Rr3GPg@mail.gmail.com>
Date: Fri, 03 Feb 2012 17:18:00 -0600
Message-ID: <CAC8QAcc-8KC7c+joRSRn8vTMGYSGZQHdfcBdWUKsHx=7v4=zxA@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Cameron Byrne <cb.list6@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: v6ops v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
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: Fri, 03 Feb 2012 23:18:02 -0000

On Fri, Feb 3, 2012 at 4:54 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
> On Fri, Feb 3, 2012 at 2:37 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
>> Hi Fred,
>>
>> I have technical concerns:
>>
>> - RFC 6146 does use DNS64 as an integral component. In this draft
>> DNS64 is not used however RFC 6146 is referenced. I think that this
>> point should be clarified instead of just giving a reference to 6146.
>>
>
> RFC6146 is stateful NAT64.  It does not require DNS64.  They are
> completely decoupled.  RFC6146 can function fine without DNS64.
> draft-mawatari-v6ops-464xlat can also function fine without DNS64, in
> my particular implementation i choose to use DNS64 since it reduces a
> layer of translation in most of *my* cases.


My point was to ask you to add at least one paragraph explaining how
DNS64 is avoided.

>
>> - As you will remember, in 3GPP-IETF workshop in 2010, pnat proposal
>> was discussed in depth. I think 464XLAT is very much like pnat. The
>> workshop did not endorse such approaches because of UE modification
>> requirement. Instead, dual stack network was endorsed.
>>
>
> PNAT, AFAIK, had an on-host DNS64 ENR function and specified ALGs.  It
> was overall a bit more complicated, and eventually that work evolved
> into the BIH work that has been approved as an RFC.   PNAT was also
> standards track work, as where this draft is informational.  From my
> perspective, the BIH work does not solve my stated problem scope since
> it is only scoped for IPv4 applications communicating with IPv6-only
> servers.
>

I know the pnat story.


>> - Since Release 8, 3GPP has adopted v4v6 or dual stack PDP Context
>> which is not mentioned in the draft.
>>
>
> Why would there be a mention of that?  The scope here is IPv6-only
> access networks, not dual-stack networks.  That said, there are very
> few Release 8+ networks deployed globally. And, dual-stack faces the
> challenge of provide IPv4 addresses that are no available.
>

Because in Section 3 you have this:

This is especially cost-effective in wireless 3GPP
       network that would otherwise require two separate PDP connections
       to support IPv4 and IPv6.



Regards,

Behcet