Re: [v6ops] new draft: draft-byrne-v6ops-clatip

"cb.list6" <cb.list6@gmail.com> Thu, 31 October 2013 14:28 UTC

Return-Path: <cb.list6@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 8CDD921E805D for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2013 07:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 kHmMq+A2mrs8 for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2013 07:28:55 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B945C11E8167 for <v6ops@ietf.org>; Thu, 31 Oct 2013 07:28:54 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id b13so7391691wgh.2 for <v6ops@ietf.org>; Thu, 31 Oct 2013 07:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ba86kAaQAkkKvuYyhXB+ZbwoY2oN1CzjSAm2Vzv/FRo=; b=uY3IKCVabomaES3OWJXMSmQMual5Z0jGe5WYGlb98bh1s9VMVWXl0dZnUZv41vSYKR ym+MC4X3+BEvfcfHDjw45G7zK5TC9C2SNoWRFCqAzS2kT8StN728JExoMpsmHEzw9yE4 OS4TLzw/FEgUfgPN8usIazF5MxJDvXiOF7Jsm5tuYAaoeEBdSZhjpEKxYSMJSxIxURFm QeeLXWDA16kltzrogb81AitBW/fg7lsqWSvM2iAFBvfUlAYzZMmZ8c72TAnl8UtjD9RP dQgm6hQwsIRdFNkG1m8GognsfKNj3v74S+ymLd8LrzsX73YJqUhaqmMlJKDQA/OqRvRx 24sw==
MIME-Version: 1.0
X-Received: by 10.180.76.69 with SMTP id i5mr7134957wiw.34.1383229733749; Thu, 31 Oct 2013 07:28:53 -0700 (PDT)
Received: by 10.216.99.68 with HTTP; Thu, 31 Oct 2013 07:28:53 -0700 (PDT)
Received: by 10.216.99.68 with HTTP; Thu, 31 Oct 2013 07:28:53 -0700 (PDT)
In-Reply-To: <CAKD1Yr0hV_Hoje24EisakxBZLseZo_oXtCuKjUBHKH0U-71U9w@mail.gmail.com>
References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237A6BA2@xmb-aln-x02.cisco.com> <CAD6AjGTw3+EjdiYYEuMRZEwBV7y8oE5DRDi9cJ41UVFmfbFN-A@mail.gmail.com> <CAKD1Yr0hV_Hoje24EisakxBZLseZo_oXtCuKjUBHKH0U-71U9w@mail.gmail.com>
Date: Thu, 31 Oct 2013 07:28:53 -0700
Message-ID: <CAD6AjGS-VB8RX6moQgz2D8itVAKVX97dxqQ_G4=w2CKR+9MjZQ@mail.gmail.com>
From: "cb.list6" <cb.list6@gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary="f46d043c7e68ec48de04ea0a4485"
Cc: draft-byrne-v6ops-clatip@tools.ietf.org, "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip
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: Thu, 31 Oct 2013 14:28:55 -0000

On Oct 31, 2013 7:16 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Oct 31, 2013 at 11:04 PM, cb.list6 <cb.list6@gmail.com> wrote:
>>
>> The address is never on the wire from CLAT, and that topology should
never occur since both 464xlat emit only ipv6, so there should be no case
where the transition happens twice AND that on-path address responds...
>>
>> But you made me think about the case of  tracerouting from 464xlat node
to a ds-lite node across the ipv6 internet... And  that b4 does not use the
specific addresses reserved for b4s.  In this case, the b4 can send a icmp
ttl exceeded to the clat, where the clat will see the packet with a
possible same source and destination
>
> But that can't happen, right? Nobody will ever see either the 464xlat IP
address or the DS-Lite IP address, because neither ever appears on the wire
- both terminals will see the public IPv4 address of the other side.
>

You are right.  In the case I was thinking of I overlooked that the aftr
would translate the ipv4 to public before returning towards the clat.

Furthermore, I doubt the range would be allowed to be translated to a
public ipv4 as a matter of policy on the aftr

CB
> Even if they pass each other their IP addresses through some other
mechanism (e.g., SIP), that's no different from the case where two machines
talk to each other and both have the IPv4 address 192.168.1.2.