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

Rémi Després <despres.remi@laposte.net> Thu, 06 October 2011 15:36 UTC

Return-Path: <despres.remi@laposte.net>
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 15F8921F8DA2 for <softwires@ietfa.amsl.com>; Thu, 6 Oct 2011 08:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.856
X-Spam-Level:
X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 uSfU33df6b0k for <softwires@ietfa.amsl.com>; Thu, 6 Oct 2011 08:36:43 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 401EF21F8DA0 for <softwires@ietf.org>; Thu, 6 Oct 2011 08:36:43 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id 6DC6E7000158; Thu, 6 Oct 2011 17:39:53 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2411.sfr.fr (SMTP Server) with ESMTP id 54C087000152; Thu, 6 Oct 2011 17:39:48 +0200 (CEST)
X-SFR-UUID: 20111006153948347.54C087000152@msfrf2411.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <05DF0672-BE68-4DA2-8094-7B314E416A1A@employees.org>
Date: Thu, 06 Oct 2011 17:39:53 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EFC2E1C-ACBB-49FE-94C5-B3A10292B0F8@laposte.net>
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>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1084)
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: Thu, 06 Oct 2011 15:36:44 -0000

Hi Ole,
I just found I didn't answer this mail directly.
In case other exchanged mails wouldn't have answered the point, please see below.

Le 1 oct. 2011 à 04:31, Ole Troan a écrit :

> Remi,
> 
>>>>> what are the requirements for a globally unique interface-id? how is it going to be used?
>>>>> both for encapsulation and translation?
>>>> 
>>>> In both cases, the CE node can recognize 4rd packets, and process them as such, without preempting any IID value that might be a legitimate value for a host behind the CE.
>> 
>> 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.

The proposed solution doesn't impact the forwarding behavior of any function that isn't specifically a 4rd function.


> I don't understand what requirements you are basing this 'solution' on.

Design objectives are listed in Sec 4. 
They include:
- Possibility of IPv6 routing plans that have no constraints related to IPv4 residual deployment.
- Possibility (even in this case) to assign differentiated sharing ratios. This is achieved by having lengths of port-set IDs determined by lengths  of CE IPv6 prefixes. 


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

I don't completely follow the proposal, and what you want to avoid.
In any case, the discussion should now focus on the proposed unified address mapping.
Agreed?  


> note that I'm not arguing against having a defined IID for dIVI/4rd, that's nice for pretty printing like what we do for ISATAP.

Good, then.

Cheers,
RD



> 
> cheers,
> Ole
> 
>