[Softwires] Section 5.2 of draft-ietf-softwire-map-02

Tom Taylor <tom.taylor.stds@gmail.com> Sat, 05 January 2013 00:32 UTC

Return-Path: <tom.taylor.stds@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 450D821F8A9B for <softwires@ietfa.amsl.com>; Fri, 4 Jan 2013 16:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAZi3zC4zJGB for <softwires@ietfa.amsl.com>; Fri, 4 Jan 2013 16:32:32 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 340B721F8A6D for <softwires@ietf.org>; Fri, 4 Jan 2013 16:32:24 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id c12so20251643ieb.37 for <softwires@ietf.org>; Fri, 04 Jan 2013 16:32:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=OLpwBtKN9d7/+l8ttwbT1l2ucAzDCEe8YGptjGNEpaU=; b=ElZSdM6JfWzaqNPefu0rATSg2w8LAWeyxzqk11vBo8dX3P4Psj5SyrpQJa9MZoU/qI Q9ymyAnZJofC7Dd4nTs0zx8opKjyNYo/qvMcgkzejjZPpKonEnplWyBzyBid6wQBgDxP /lkiOuv10wzqvEYw5tfyn3LnzRzUKVz+YBMnnNRA3CclFnShVBF6hvAynb1mcWoeugsS n8NXvG+u+MBRBNTA0XxulLb6kHrdwJ6d3bMaCldH1ewo635Kf4aceNYbRkEk+SltPCtU PzdkSB8Ne4lhEnAJCSmqHHMXoNsX+WELPdgUdmE9uHqtoe8wSi02MRyjm0ZC/zQoXKIs FwOQ==
X-Received: by 10.42.72.132 with SMTP id o4mr30035431icj.44.1357345943803; Fri, 04 Jan 2013 16:32:23 -0800 (PST)
Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id k5sm981169igq.9.2013.01.04.16.32.21 (version=SSLv3 cipher=OTHER); Fri, 04 Jan 2013 16:32:23 -0800 (PST)
Message-ID: <50E77496.2080808@gmail.com>
Date: Fri, 04 Jan 2013 19:32:22 -0500
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Softwires <softwires@ietf.org>, Ole Troan <ot@cisco.com>, Wojciech Dec <wdec@cisco.com>, Xing Li <xing@cernet.edu.cn>, congxiao@cernet.edu.cn, satoru.matsushima@g.softbank.co.jp, tetsuya@ipinfusion.com
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130104-0, 04/01/2013), Outbound message
X-Antivirus-Status: Clean
Subject: [Softwires] Section 5.2 of draft-ietf-softwire-map-02
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, 05 Jan 2013 00:32:33 -0000

I find Section 5.2 of draft-ietf-softwire-map-02 very confusing as it 
stands. It doesn't help that the figures are misplaced and algebraic 
symbols are reused or used redundantly. I believe the explanation of the 
various address derivations has to be tied together with some 
introductory text, then at least one step has to be added at the start. 
The flow should go something like this:

5.2 Deriving the MAP Address From the End-User IPv6 Prefix and the Basic 
Mapping Rule

5.2.1 Structure of the End-User IPv6 Prefix

5.2.2 Deriving the MAP IPv6 Prefix

5.2.3 Deriving the MAP IPv6 Interface Identifier

5.2.4 Deriving the Port-Set Associated With the CE

5.2.5 Example

The text fleshing this out follows. If something seems wrong, blame my 
misunderstanding and please correct me.

I see that, contrarily to a previous note, it isn't necessary to specify 
the sharing ratio explicitly as part of the Mapping Rule.

Hope this helps.
Tom Taylor


5.2 Deriving the MAP IPv6 Address From the End-User IPv6 Prefix and the 
Basic Mapping Rule

As indicated above, the end-user IPv6 prefix is an IPv6 prefix 
provisioned on the CE and unique to it. This prefix has a special 
structure described in the next section.

The MAP IPv6 address is the address used by other MAP nodes to reach the 
MAP function of this node. It is constructed using the end-user IPv6 
prefix and other information contained in the Basic Mapping Rule.

5.2.1 Structure of the End-User IPv6 Prefix

The end-user IPv6 prefix is illustrated in Figure 3. It consists of two 
parts: a common initial prefix of length n bits followed by a part of 
length (o + p) bits that is specific to the CE. The initial n bits MUST 
match the IPv6 prefix given by the Basic MAP Rule applicable to the CE. 
The o bits immediately following the common initial prefix constitute 
the Embedded Address (EA), described further below. Additional bits are 
optional.


     |          n bits         |  o bits   |    p bits    |
     +-------------------------+-----------+--------------+
     |  Common initial prefix  |  EA bits  | Opt. add't'l |
     +-------------------------+-----------+--------------+

               Figure 3: End-user IPv6 prefix format

5.2.2 Structure of the Embedded Address Field (EA Bits)

Recall that the Basic Mapping Rule provides the following parameters:

       *  Rule IPv6 prefix (including prefix length n)

       *  Rule IPv4 prefix (including prefix length r). This prefix
          and length MAY be provisioned either as an explicit part
          of the Mapping Rule or by other means (e.g., DHCPv6). The
          length r in the Mapping Rule MAY be 0, indicating that
          the EA bits contain a complete prefix or address (see
          below).

       *  Rule EA-bits length (o)

       *  Excluded ports (default, the first block of 4096 ports)
[Comment: I don't think this is operationally necessary. Would an 
operator want to avoid any more than the system ports? More get pulled 
in because of the block size, but that is implicit and need not be 
spelled out in the Mapping Rule.]

       *  Offset bits (a, from Section 5.1.3) (default, 4 bits,
          corresponding to a block size of 4096)

One can see that the position of the EA bits within the end-user IPv6 
prefix is determined by the values n and o in the Basic Map Rule.

The Embedded Address field may be interpreted in any one of four ways, 
depending on the values of r and o in the Basic Mapping Rule. In all 
cases, the ability to include part of all of an IPv4 address in that 
field allows multiple CEs to use the same Basic Mapping Rule if so desired.

a. Partial or complete IPv4 prefix:

The sum r + o is less than 32. The complete prefix is equal to the 
concatenation of the Rule IPv4 prefix (or its separately provisioned 
equivalent) and the contents of the Embedded Address field, as shown in 
Figure 4.

                    |   r bits    | o bits  |
                    +-------------+---------+
                    |  Rule IPv4  | EA bits |
                    +-------------+---------+
                    |       < 32 bits       |

                       Figure 4: IPv4 prefix

b. Partial or complete IPv4 address:

The sum r + o is 32 exactly. The complete address is equal to the 
concatenation of the Rule IPv4 prefix (or its separately provisioned 
equivalent) and the contents of the Embedded Address field, as shown in 
Figure 5.

                    |   r bits    | o bits  |
                    +-------------+---------+
                    |  Rule IPv4  | EA bits |
                    +-------------+---------+
                    |        32 bits        |

                Figure 5: Complete IPv4 Address

c. Shared IPv4 address:

The sum r + o is greater than 32. The EA bits contain the concatenation 
of an IPv4 suffix with the PSID identifying the port-set associated with 
this CE. The length of the IPv4 suffix is given by the difference (32 - 
r), with the remaining bits belonging to the PSID. Figure 6 shows the 
derivation of the shared IPv4 address and the PSID from the Rule IPv4 
address (or its separately provisioned equivalent) and the Embedded 
Address field. The width (o - (32 - r) bits) of the PSID field MUST be 
equal to the logarithm base 2 of the sharing ratio R (i.e., the value k 
defined in Section 5.1.1).


                   |     Embedded Address (EA) (o bits)       |
                   +---------------------+--------------------+
                   |    (32 - r) bits    |  o - (32 - r) bits |
                   +---------------------+--------------------+
                   | IPv4 Address suffix |    Port-Set ID     |
                   +---------------------+--------------------+
                    \                     \
                     \                     \
                      \                     \
         |   r bits    |   (32 - r) bits     |
         +-------------+---------------------+
         |  Rule IPv4  | IPv4 Address suffix |
         +-------------+---------------------+
         |               32 bits             |
         |         Shared IPv4 address       |


           Figure 6: Derivation of Shared IPv4 Address and PSID
                From the EA Bits and Rule IPv4 Prefix

d. Address Independence

    The length r MAY be 32, with no part of the IPv4 address embedded
    in the EA bits.  This results in a mapping with no dependence between
    the IPv4 address and the IPv6 address.  In addition the length o
    MAY be zero (no EA bits embedded in the End-User IPv6 prefix),
    meaning that the PSID is also provisioned using, e.g., a DHCP option.

5.2.2 Deriving the MAP IPv6 Prefix

The MAP IPv6 prefix has the structure shown in Figure 7. The MAP IPv6 is 
created by combining the End-User IPv6 prefix with the all-zero subnet 
ID and the MAP IPv6 interface identifier.



  |           n + o + p bits       | s bits  |   128-n-o-p-s bits    |
  +--------------------------------+---------+------------+----------+
  |      End-user IPv6 prefix      |subnet ID|     interface ID      |
  +--------------------------------+---------+-----------------------+

                        Figure 7: MAP IPv6 Address Format

The end-user IPv6 prefix was described in Section 5.2.1.

The subnet ID field, as just indicated, MUST be all zeroes. A MAP node 
MUST reserve the all-zero subnet ID for the purpose of MAP.

The interface ID MUST be constructed as described in the next sub-section.

5.2.3 Deriving the MAP IPv6 Interface Identifier

    The Interface identifier format of a MAP node is based on the format
    specified in section 2.2 of [RFC6052] for a prefix length of 64
    bits, with the PSID field added as a suffix if present, as shown
    in Figure 8.



    +--+---+---+---+---+---+---+---+---+
    |PL|   8  16  24  32  40  48  56   |
    +--+---+---+---+---+---+---+---+---+
    |64| u | IPv4 address  |  PSID | 0 |
    +--+---+---+---+---+---+---+---+---+


                                  Figure 8

    In the case of an IPv4 prefix, the IPv4 address field is right-padded
    with zeroes up to 32 bits.  The PSID field is left-padded to create a
    16 bit field.  For an IPv4 prefix or a complete IPv4 address, the
    PSID field is zero.

    If the End-user IPv6 prefix length is larger than 64, the most
    significant parts of the interface identifier are overwritten by the
    prefix.

[COMMENT: the above is copied almost exactly from the existing text, 
with some expansion in the first paragraph. If the u bits are 
overwritten, this no longer conforms to RFC 6052. Maybe that attribution 
should be deleted?]

5.2.4 Deriving the Port-Set Associated With the CE

Looking back at Section 5.1 and Figure 2 in Section 5.1.1, recall that 
the set of port numbers valid for a given CE is calculated using the 
PSID and two indices i and j. Assume as in Section 5.1.1 that the 
sharing ratio R and the maximum number M of consecutive ports allocated 
to a given CE are powers of 2. Then the block index j ranges from a 
minimum that excludes the system ports, up to the maximum supported by a 
field that is 'a' bits wide. The PSID occupies a field k bits wide, and 
the port index i occupies the remaining low-order bits of the port number.

 From the immediately preceding sub-sections, we have:

    a is given directly as part of the Basic Mapping Rule;

    k may be assumed to have the value o - (32 - r), the width of the
    PSID field in the EA bits, where o and r come from the Basic Mapping
    Rule;

    the width m of the port index field is equal to the remainder
    16 - a - (o - (32 - r)), or 48 - r - a - o.


5.2.4 Example

    In the following example, only the suffix (last 8 bits) of the IPv4
    address is embedded in the EA bits (r = 24), while the IPv4 prefix
    (first 24 bits) is given in the BMR Rule IPv4 prefix.

      Given:
       End-user IPv6 prefix:  2001:db8:0012:3400::/56
       Basic Mapping Rule:    {2001:db8:0000::/40 (Rule IPv6 prefix),
                              192.0.2.0/24 (Rule IPv4 prefix),
                              16 (Rule EA-bits length)}
       PSID offset:           4 (default value as per section 5.1.3)

The above information gives directly:
       n = 40
       r = 24
       o = 16
       a = 4
Since r + o = 40 > 32 and r is less than 32, we are looking at a shared 
IPv4 address rule.

Now we can derive the other values we need to calculate the port-set:

       EA bits are bits 41-56 of the end-user IPv6 prefix, or 0x1234
       PSID field width k = 16 - (32 - 24) = 8 bits
       PSID itself is 0x34
       Port index field width m = 16 - a - k = 4 bits

 From the above one can determine that the port-set consists of a range 
of 16 consecutive values in each of 15 blocks (the first potential block 
being excluded). The ranges are as follows:
       0x1340-0x134f   ( 4928- 4943)
       0x2340-0x234f   ( 9024- 9039)
           ...             ...
       0xf340-0xf34f   (62272-62287)

As shown in Figure 6, the shared IPv4 address is obtained by 
concatenating the Rule IPv4 prefix with the suffix given by the upper 8 
bits of the EA bit field. Those upper 8 bits are 0x12, or 18 decimal. 
Hence the shared IPv4 address is 192.0.2.18.

Given that the end-user IPv6 prefix is 56 bits long, a subnet identifier 
field of 8 bits can be allocated while conforming with the interface 
identifier structure described in Section 5.2.3. The complete MAP IPv6 
address then becomes:
      2001:db8:0012:3400:00a0:0002:1200:3400