IETF Logo Mail Archive

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

Jacni Qin <jacni@jacni.com> Sat, 08 October 2011 15:04 UTC

Return-Path: <jacni@jacni.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 535E421F8B81 for <softwires@ietfa.amsl.com>; Sat, 8 Oct 2011 08:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.271
X-Spam-Level:
X-Spam-Status: No, score=-0.271 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, SARE_RECV_IP_222064=1.666]
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 gG5+EjtfqO+t for <softwires@ietfa.amsl.com>; Sat, 8 Oct 2011 08:04:08 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 95BB621F8B27 for <softwires@ietf.org>; Sat, 8 Oct 2011 08:04:08 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id B9D0C38006D for <softwires@ietf.org>; Sat, 8 Oct 2011 11:07:24 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id A16B434012C for <softwires@ietf.org>; Sat, 8 Oct 2011 23:07:22 +0800 (CST)
Received: from [192.168.1.4] (unknown [222.65.34.251]) by app (Coremail) with SMTP id +AWowJArCAQpZ5BOfjMVAA--.27818S2; Sat, 08 Oct 2011 23:07:21 +0800 (CST)
Message-ID: <4E906793.2080505@jacni.com>
Date: Sat, 08 Oct 2011 23:09:07 +0800
From: Jacni Qin <jacni@jacni.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: Ole Troan <otroan@employees.org>
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> <3C29CE19-E03A-4AC5-959A-7931FE5B9B04@employees.org> <CABv173WfM+93wRj+k1JSRdarCwXOr6q-kRrT=8p=dewDn3jn1g@mail.gmail.com> <845CF8A3-0463-4D52-A5DC-7AE697FA1208@employees.org>
In-Reply-To: <845CF8A3-0463-4D52-A5DC-7AE697FA1208@employees.org>
Content-Type: multipart/alternative; boundary="------------090505030709020405090905"
X-CM-TRANSID: +AWowJArCAQpZ5BOfjMVAA--.27818S2
X-Coremail-Antispam: 1UD129KBjvJXoW7AFykXry5AFWxGF4UCFy8Xwb_yoW8WF4UpF Z3Grs8GF4DJr18C397Xw40v34FkF1kX3WrJF15trnxCr98Wr4jyr1jk345J3y5Xr1rJw4a vrWUCFWUGay5ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUcYb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK6IIYrVAqxI0j4VAqrcv_Jw1UGr1DM2vj6xkI62vS6c8GOVWU tr1rJFylYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcV AKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI 7VAKI48JMxCIbVAxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2Kf nxnUUI43ZEXa7IU038n7UUUUU==
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEPEko7lOc3UAAAs4
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: Sat, 08 Oct 2011 15:04:09 -0000

hi,

Inline please,

On 10/6/2011 10:03 PM, Ole Troan wrote:
>>> i couldn't understand why we "don't see such limitation in 4v6 translation". 4via6 translate the private ipv4 address with 4rd mapping rule while the public ipv4 address with RFC6052 algorithm, right? can the both case work fine if an ISP can only get a fairly long IPv6 prefix, like /40 or even longer?
>>>
>>> Yes, if ISP has /32 IPv6 address, then how to embed 32 bits IPv4 address and PSID in the first 64 bits?
>> only part of the IPv4 address would be embedded into the first 64 bits (not that I think that boundary should be "hard").
>> e.g. if the SP has the prefix 10/8. the user the address 10.1.2.3. then only "1.2.3" would be embedded in the address.
>> just like what's done for 6rd.
>>
>> Thanks, Ole. That’s the point! In this case , you can only have part of the IPv4 address embedded in the first 64 bits. This embedding does work for encapsulation or tunneling, but can NOT work for stateless double translation, which requires the whole IPv4 address+PSID embeded for any IPv6 prefix length.
> right, for the outside domain traffic.
> putting the state into the IPv6 destination address doesn't affect routing.
> so this works fine with the case where you give a user a /56, where you have to have efficient encoding. for the external to the domain traffic you need to encode the full IPv4 address.
The phase to get v4 space from delegated prefix is different from 
forming IPv6 address for sending traffic.


Cheers,
Jacni

>
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

v2.23.0 | Report a Bug | By Email