Re: [Softwires] 4rd-addmapping - Possible independence of the IPv6 addressing plan from IPv4 prefixes

Maoke <fibrib@gmail.com> Fri, 21 October 2011 11:34 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 96FFA21F8BA8 for <softwires@ietfa.amsl.com>; Fri, 21 Oct 2011 04:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.217
X-Spam-Level:
X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.081, 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 5VBlkGVGVjQI for <softwires@ietfa.amsl.com>; Fri, 21 Oct 2011 04:34:18 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7BAF21F8BA6 for <softwires@ietf.org>; Fri, 21 Oct 2011 04:34:18 -0700 (PDT)
Received: by qyk34 with SMTP id 34so389049qyk.10 for <softwires@ietf.org>; Fri, 21 Oct 2011 04:34:18 -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=GZEvSflfR1u5n5xziwTU8bM9tmP43Odg2LZrcoyDiCg=; b=NwLQdTKM+v+PdreKDGadOcmyvdfNuZUBwd/L9yHLfSpIBchX5dgwhSbht5wnkBP2eK EHkTybAEW+YrapKyiAw8A+M9rEjqfCaunHNd14fRe/eQGzanAUNQOaJY1JU5p/bjaHEP lxADOTgbmR4Fk5z/S+wBdwkTlJ87xcAspZtY4=
MIME-Version: 1.0
Received: by 10.229.59.78 with SMTP id k14mr603236qch.69.1319196858066; Fri, 21 Oct 2011 04:34:18 -0700 (PDT)
Received: by 10.229.175.205 with HTTP; Fri, 21 Oct 2011 04:34:18 -0700 (PDT)
In-Reply-To: <91111240-FEA5-49F4-B877-197FFA46AE1B@laposte.net>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <CAFUBMqUvrP-s1yrJ0=ToAA_SvRLWQtq7JCTtpASNiS1GAxdSNQ@mail.gmail.com> <4E9B9BC5.2090200@jacni.com> <CAFUBMqUS1cATWr07Os4d6aLUbNaVwuOCcthObOiMPuDv8VfU1g@mail.gmail.com> <4E9BE001.3060202@jacni.com> <6CADC58598A4D249AD3B5026CE8CC33906D75AC8@CI-EXMB-09V.bb.local> <CAFUBMqW7xqxwzToxn1=0y4q48Dr5U8rx3pDoavcWGhPyO-OLpw@mail.gmail.com> <927947AB-FD61-4CCA-8E42-2DEC1854F2EA@free.fr> <CAFUBMqX9rrmTpksw7R4_59=rN0qDVkA_6y5B5cBP_7zgaRt=rQ@mail.gmail.com> <91111240-FEA5-49F4-B877-197FFA46AE1B@laposte.net>
Date: Fri, 21 Oct 2011 20:34:18 +0900
Message-ID: <CAFUBMqUN3oZ-ZhDsQHhLzgrW5U9xVmUDiAvcpsG-pUKF3tBb4g@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="0016e6506c161d28f204afcd7406"
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] 4rd-addmapping - Possible independence of the IPv6 addressing plan from IPv4 prefixes
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: Fri, 21 Oct 2011 11:34:19 -0000

Remi,

thanks for the further explanation. let me remove the cleared part and make
the message shorter. :P

2011/10/21 Rémi Després <despres.remi@laposte.net>

>
>
>
>>   (B) IPv4 considerations
>> (B1) List all (non overlapping) IPv4 prefixes Hi that are available for
>> IPv4 residual deployment.
>> (B2) Take enough of them, among the shortest ones, to get a total space
>> whose size M is a power of two (M = 2 ^ m), and includes a good proportion
>> of the available IPv4 space (ref
>> www.ietf.org/mail-archive/web/softwires/current/msg02261.html).
>> (B3) For each IPv4 prefix Hi of length hi, choose a "Rule index" Ri of
>> length ri = m - hi. All these indexes must be non overlapping prefixes (e.g.
>> 0, 10, 110, 111 for one /10, one /11, and two /12).
>>
>
> Oops, another bug :-(.
> The right formula for ri is:  ri = m - (32 - hi)
>

yeah. :P i didn't discover that.

The PSID is WITHIN the /60 (at its end).
>

to clarify: WITHIN the /60 means within the address block of the /60, not
*within the first 60 bits*, (then at its end = starts from 61st bit),
right?


>
> The IPv6 /64 prefix to be used to reach a CE contains:
> 1) The Rule IPv6 prefix (that of the rule whose IPv4 prefix matches the
> IPv4 destination)
> 2) The IPv4 suffix (that part of the IPv4 destination that follows the IPv4
> prefix of the matching rule)
>

the CE IPv6 prefix = 1) + 2), right?


> 3) The PSID (whose length is known iff the matching rule specifies a CE
> IPv6-prefix length)
>

the EA bits = 2) + 3), right?


>
> 4) If the PSID length is unknown, the "PSID complement" that completes the
> Max PSID.
> 5) A 0 padding if fields 1 to 4 don't reach 64 bits
>
> Note 1: If a Domain-IPv6-suffix option is used, the PSID length is
> necessarily known, and the PSID complement is then replaced by the Domain
> IPv6 suffix found in the matching rule. (ref draft-murakami-softwire-4rd-01.
>

it seems to me that the draft-murakami-softwire-4rd-01 hasn't explain how do
we use the "Domain IPv6 suffix", :(


> Note 2: If ordinary CE IPv6 prefixes are /60s, the PSID complement has
> typically 4 bits (to fit in the /64).
> The only exception is if the sharing ratio needs to exceed 256, so that the
> PSID length exceeds 8. Then, the PSID complement of less than 4 bits.
>
> on the other hand, there is a limitation. if c + m > 64, the above address
> planning is not deployable, but with our effort of maximum compression,
>
> we believe the undeployable case rarely happens for normal providers,
> right?
>
>
> Yes.
>
> The only impossibility is if the available IPv4 space is so small that no
> sharing ratio can be sufficient for the number of IPv4 shared addresses to
> equal the number of ordinary CE IPv6 prefixes.
>

sure. in this case we can help nothing.


> If the above is still unclear (or bugged!), thanks for letting me know.
>
>
Regards,
> RD
>