Re: [Softwires] MAP Open issues: Back to requirements

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Wed, 09 November 2011 01:24 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.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 7ED0D11E8095 for <softwires@ietfa.amsl.com>; Tue, 8 Nov 2011 17:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.126
X-Spam-Level:
X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vZEeUOuCcpMt for <softwires@ietfa.amsl.com>; Tue, 8 Nov 2011 17:24:42 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8690E11E80AD for <softwires@ietf.org>; Tue, 8 Nov 2011 17:24:42 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00CHID8XB2@szxga03-in.huawei.com> for softwires@ietf.org; Wed, 09 Nov 2011 09:24:33 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00FK4D8JCP@szxga03-in.huawei.com> for softwires@ietf.org; Wed, 09 Nov 2011 09:24:33 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV48875; Wed, 09 Nov 2011 09:24:33 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 09:24:29 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 09:24:27 +0800
Date: Wed, 09 Nov 2011 01:24:27 +0000
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
In-reply-to: <E5F4DC211930DB488C0563E1C93FB748169D0F3D@dfweml503-mbx>
X-Originating-IP: [10.212.245.163]
To: "softwires@ietf.org" <softwires@ietf.org>
Message-id: <C0E0A32284495243BDE0AC8A066631A80C1D9C2E@szxeml526-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-US
Content-transfer-encoding: 7bit
Accept-Language: en-US, zh-CN
Thread-topic: MAP Open issues: Back to requirements
Thread-index: AQHMnhihXxJI1Txzn0KxAVSZd1FF45WjUNJwgABsUkCAAAItoA==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <C0E0A32284495243BDE0AC8A066631A80C1D84DF@szxeml526-mbs.china.huawei.com> <E5F4DC211930DB488C0563E1C93FB748169D0F3D@dfweml503-mbx>
Subject: Re: [Softwires] MAP Open issues: Back to requirements
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: Wed, 09 Nov 2011 01:24:43 -0000

I am still unclear about this:
Why do we require multiple mapping rules? How does it support multiple IPv4 subnets. End User IPv6 prefix is generated from the Rule IPv6 Prefix + EA bits. So how does the CE know which Rule to use to generate this.


Thanks,
Tina

> From: Ole Troan <ot@cisco.com>
> Date: November 8, 2011 14:14:36 GMT+01:00
> To: Softwires WG <softwires@ietf.org>
> Subject: MAP Open issues: Back to requirements
> 
> the discussions we have had in the design team and on the softwires mailing list reflect that many of us have different views on what a stateless IPv4 over IPv6 solution should look like. there is an astounding amount of innovation in this space; for every problem found there are solutions offered. no stone has been left unturned.
> 
> we are suffering from feature creep.
> 
> I'm asking the working group members to voice an opinion on these selected requirements, so that we can try to get some features pruned, and build some more consensus on a complete MAP solution before Taipei.
> 
> I would beg the design team members to step back for a day or two, to let the rest of the working group speak up.
> 
> 1) Granularity of port range assignments.
>   Do we need to support different port ranges within a single IPv4 shared address? Within a single IPv4 subnet, or
>   between multiple IPv4 subnets?
> 
>   Trade-off: Differentiated port-range size within a single mapping rule, is solved with the Max PSID solution. Resulting in
>              destination spray (MAP traffic sent across a whole End-user prefix (e.g. /56) instead of single destination address.)
> 
> 2) Provisioning with DHCPv6.
>   Must the MAP DHCPv6 option be the same for all MAP CEs, or can it be different, depending on e.g.
>   which IPv4 subnet is used, which BR should be used and so on?
> 
>   Trade-off: If the DHCPv6 option is the same for all MAP CEs and you have a requirement to use different BRs for different IPv4
>              subnets, then the consequence is that each mapping rule needs an BR prefix/address _and_ that the CE must use
>              source address based forwarding to reach the correct BR for the right IPv4 subnet.
> 
> 
> 3) Co-existence of native IPv6 and MAP traffic within a /64.
>   Must it be possible to have both native IPv6 nodes _and_ MAP traffic within the same IPv6 prefix?
>   There may be deployments like 3G, that in Release prior to 10, only provides a single /64 to a MAP node.
> 
>   Trade-off: If this requirement is combined with the "Max PSID", then the consequence of this is that a "V" flag (position 71/72)
>              in the modified EUI-64 identifier, or using the IANA OUI and trusting that to be handled correctly by implementations
>              is needed. If a unique /128 can be used for MAP traffic, then this can trivially be supported.
> 
> 4) Checksum adjustment in IPv6 address.
>   Must a double translation solution generate IPv6 packets with a valid L4 checksum?
>   If so, is there any benefit in adjusting the checksum by tweaking bits in the IPv6 address versus updating the L4 checksum?
> 
>   Trade-off: The consequence of fiddling with the bits in the IPv6 address, is "destination spray".
> 
> 5) Interface-identfier.
>   Must it be possible for a device in the middle without the MAP rules, to parse the IPv6 address to identify the encapsulated or
>   translated IPv4 addresses and port sets? Does encoding the IPv4 address and PSID in the interface-identifier simplify
>   operation?
> 
>   Trade-off: IPv4 address, PSID and Length parameter must be encoded (and possibly enforced) in the interface-id.
> 
> just like for an annual meeting in a public company, you'll get advice from the board (i.e. me the editor (there is no consensus in the design team)) what to vote:
> 
> 1) port-range size granularity is per IPv4 subnet. 
> 2) each MAP CE is provisioned with 'correct' information for it. (DHCPv6 option is the same for all CEs using the same rule, but different
>   within a domain).
> 3) Co-existence is only supported when a /128 is used for terminating MAP traffic. Co-existence is not supported in the case of an
>   IPv4 prefix and translation.
> 4) Checksum adjustments are done in L4 header
> 5) Only the full IPv4 address is encoded in the interface-id.
> 
> cheers,
> Ole
>