IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Thu, 06 October 2011 10:50 UTC

Return-Path: <ichiroumakino@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 0E60D21F8C33 for <softwires@ietfa.amsl.com>; Thu, 6 Oct 2011 03:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.533
X-Spam-Level:
X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 K9DqozN0tsf7 for <softwires@ietfa.amsl.com>; Thu, 6 Oct 2011 03:50:21 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D390821F8C1F for <softwires@ietf.org>; Thu, 6 Oct 2011 03:50:20 -0700 (PDT)
Received: by wwn22 with SMTP id 22so7652818wwn.1 for <softwires@ietf.org>; Thu, 06 Oct 2011 03:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cxB8Z/xgFUMu1ZWL4Xkw9JQv4LZquQ48h1K91sMvJyU=; b=MFJX6OGRJZVu48P+UPUn04xa13tWPGS9Xawy6hVKqP8cWtiYH0DtO0wKt1OGqQ49gO a5Xw8069/L9PvOROCh8DfqNea95G7wVsJkI9RPW5iXlc2wNrA+t7XhZl7I4J7I4v4770 rTAeia3TUMjze47msChaj+C7KspQ7bPcYF/1k=
Received: by 10.216.134.168 with SMTP id s40mr951977wei.50.1317898410645; Thu, 06 Oct 2011 03:53:30 -0700 (PDT)
Received: from dhcp-10-61-97-42.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fj1sm5604029wbb.13.2011.10.06.03.53.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Oct 2011 03:53:29 -0700 (PDT)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CABv173U4wOBYBjM+kaCfHM1ksNPSk1WW_JvMTf1Y1=b_-X=jrg@mail.gmail.com>
Date: Thu, 06 Oct 2011 06:53:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C29CE19-E03A-4AC5-959A-7931FE5B9B04@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>
To: Congxiao Bao <cx.cernet@gmail.com>
X-Mailer: Apple Mail (2.1084)
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: Thu, 06 Oct 2011 10:50:22 -0000

> 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.

cheers,
Ole

v2.23.0 | Report a Bug | By Email