Re: [Softwires] 4rd Address Mapping - version-01

Qiong <bingxuere@gmail.com> Sun, 02 October 2011 00:56 UTC

Return-Path: <bingxuere@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 772CF21F8E87 for <softwires@ietfa.amsl.com>; Sat, 1 Oct 2011 17:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.526
X-Spam-Level:
X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zKpUWUFpv2Ya for <softwires@ietfa.amsl.com>; Sat, 1 Oct 2011 17:56:17 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7E0821F8E83 for <softwires@ietf.org>; Sat, 1 Oct 2011 17:56:16 -0700 (PDT)
Received: by iaby26 with SMTP id y26so4291496iab.31 for <softwires@ietf.org>; Sat, 01 Oct 2011 17:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QilvfZJ+rpLWozn5VTIODw9gEFGXPAqdcQN13vpbjxs=; b=yAWeg/M166grmZ9ycw2IqgvB65ht6bVJ3kelVESQOwPK5/vqDuEFj4gL3BxB5Nek2e 8qAMtQv93JFyVg1/zeK/OrZ/h31sl+ocqFZQgaKFgSDnZoAIQfpNxpq5HOzHPiUZFAP/ BORAeZeXIRAb+orW7uAIo6DhAXyg4qpo61oQo=
Received: by 10.42.197.8 with SMTP id ei8mr5146683icb.207.1317517153068; Sat, 01 Oct 2011 17:59:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.219.194 with HTTP; Sat, 1 Oct 2011 17:58:52 -0700 (PDT)
In-Reply-To: <05DF0672-BE68-4DA2-8094-7B314E416A1A@employees.org>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <B3D5FABA-72BA-4C35-A068-D823CC0A4682@laposte.net> <CAM+vMERSbGuraAC9snvGUgPBOY40m5p0SX46qfVqJaB6bHmvCw@mail.gmail.com> <D8B8F1D1-1FE7-44E1-A6C6-E1480BD91C0A@ipinfusion.com> <4E82C970.8060801@jacni.com> <3580FD83-1FD6-4A5D-9AB1-046FBE47AFBB@employees.org> <823C69D6-D040-4959-8A5A-3B1B2CAF7734@free.fr> <C1DB0E47-C4F8-4AAF-B754-379B9B47BB95@employees.org> <EC5F7306-8EA6-4707-A8EF-D8D2BEC5E3B9@free.fr> <593B5458-3276-43D7-AF32-2FB8EF899AE7@employees.org> <332BEE87-D2F4-496B-8D73-16AC7FFA2B71@free.fr> <CC3E5BBD-3C75-48F2-90E7-AFAE365AAF2F@employees.org> <F0D8CC93-E84B-4565-8A78-3D166BA88FA7@laposte.net> <05DF0672-BE68-4DA2-8094-7B314E416A1A@employees.org>
From: Qiong <bingxuere@gmail.com>
Date: Sun, 02 Oct 2011 08:58:52 +0800
Message-ID: <CAH3bfACG52APJNa2RxEmyyvG7QoEaQMo9i31gA-ZNco7w2ASTw@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Content-Type: multipart/alternative; boundary="20cf303ea63ae4e69904ae465d71"
Cc: Softwires-wg <softwires@ietf.org>, Wojciech Dec <wdec@cisco.com>
Subject: Re: [Softwires] 4rd Address Mapping - version-01
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: Sun, 02 Oct 2011 00:56:17 -0000

Hi Ole and Remi,

> This is my answer to your first (double) question.
> > If it is not enough, as suggested below, please explain what you don't
> understand.
>
> I specifically do not want a solution that changes forwarding behaviour for
> _all_ IPv6 packets.
> e.g. looking at 24 bits in the middle of an IPv6 address is such a change.
>
> I don't understand what requirements you are basing this 'solution' on.
> if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of
> the delegated prefix. then why do you need any of that?
>

Qiong : I agree that routing lookup for a provisioned /64 prefix would be
better that extracting certain bits for each IPv6 address in CE. This would
bring less change to existing routing model.

Best wishes

Qiong

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