[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