IETF Logo Mail Archive

Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Maoke <fibrib@gmail.com> Tue, 18 October 2011 02:37 UTC

Return-Path: <fibrib@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AE421F84CC for <softwires@ietfa.amsl.com>; Mon, 17 Oct 2011 19:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level:
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 UdIqWLaENrlk for <softwires@ietfa.amsl.com>; Mon, 17 Oct 2011 19:37:56 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B76921F84CB for <softwires@ietf.org>; Mon, 17 Oct 2011 19:37:56 -0700 (PDT)
Received: by qadb12 with SMTP id b12so76971qad.31 for <softwires@ietf.org>; Mon, 17 Oct 2011 19:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1QejftzYeiiYo2m1xhKQsGDJoU5AioEiqA2D0mul8Tg=; b=iJhVA7Z3HH/ktbeoFZ1gJGHy/oPZgNh9oy9dJ/hn/uqwtbi4sr8T+jxbLsBv0i1M9E RCKje2qOKDPdL3bzuNjS75Eq11KkTAI2PIEgE+yTsMkZxpWOB1fQ3RFCp94HVV+qbXIJ wyzvZvNkj5NLir5yYGB3PeeydFlyezXOpj+Hk=
MIME-Version: 1.0
Received: by 10.229.62.195 with SMTP id y3mr95375qch.31.1318905475763; Mon, 17 Oct 2011 19:37:55 -0700 (PDT)
Received: by 10.229.214.212 with HTTP; Mon, 17 Oct 2011 19:37:55 -0700 (PDT)
In-Reply-To: <C87E17E8-8686-4D01-939E-E6C7C3E5DF58@free.fr>
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net> <CAM+vMER2CBTpYOhcu63th7AJejCJ4sv0_GqeiZmwHVHEEeW1WA@mail.gmail.com> <0C2B5428-98D4-4F67-B18D-9ACA946A68E7@laposte.net> <CABv173VeFd5DVLm5XvX5+PTgW2biQpUCnW=Z7EXHj7EDG-5LUg@mail.gmail.com> <CAM+vMERXwqJWobpUsk=Pq6OkubBSCc8QFdNsRgMSyzf+1e8SgQ@mail.gmail.com> <CAFUBMqVkMQ89tffeGcBT5mJpz56mrvabe0pjdiJ-ia7XfoVhYw@mail.gmail.com> <CABv173U4wOBYBjM+kaCfHM1ksNPSk1WW_JvMTf1Y1=b_-X=jrg@mail.gmail.com> <CAM+vMETVf763VWLLCHy072NcHTi0v=cMOyjQ+u2HHa5SwiFF_A@mail.gmail.com> <CAFUBMqX01bLG4Rkn=zvT9o4Q4UF3sGCqEGd7AD0aW-ZkC9AS6w@mail.gmail.com> <CAM+vMET5J4XVbrKR9zdHXN8LqhBYJ=psYMoSXBNFzwZVUkE0YA@mail.gmail.com> <14AB4609-752F-44E2-BE75-EB414CC2ACFA@ipinfusion.com> <CAFUBMqVni_GNqmEx-FwzNUKUD1x2hN=xoe7Zc9pre4rfmGBWRw@mail.gmail.com> <C87E17E8-8686-4D01-939E-E6C7C3E5DF58@free.fr>
Date: Tue, 18 Oct 2011 11:37:55 +0900
Message-ID: <CAFUBMqWvuWCfU9Gw7YpThAeB2fk1sQ-kV4SD6XEVnHBtdb1W2w@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@free.fr>
Content-Type: multipart/alternative; boundary="0016e64b1d56600d0004af899cc6"
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2011 02:37:57 -0000

hi Remi,

2011/10/18 Rémi Després <despres.remi@free.fr>

> Hi Maoke,
>
> On 2011/10/12, you wrote:
> "... considering the double translation is a case of translation. it is
> possible that a src host with an IPv4-translatable IPv6 address generates a
> fragment header with a 32-bit identifier happening to have the first 16 bit
> as either 0x8000 or 0x0000, making a fake D bit in your current proposal."
>
> An important point is that the IP identifier needs to be unique ONLY for
> each <SRC, DST> pair.
> If 4rd addresses are deterministically recognizable (with the V octet in
> bits 64-71), there is no risk of confusion with an IP identification
> generated for another purpose than 4rd.
>

thus i understand. then you didn't try to decouple the header processing
from the mapping algorithm, right? sorry but i was confused here. :P

best,
maoke


>
> Hope it clarifies.
>
> Cheers,
> RD
>

v2.23.0 | Report a Bug | By Email