Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Leaf yeh <leaf.y.yeh@huawei.com> Wed, 12 October 2011 07:41 UTC

Return-Path: <leaf.y.yeh@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 6090421F8B15 for <softwires@ietfa.amsl.com>; Wed, 12 Oct 2011 00:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 hM76VhfwqmIE for <softwires@ietfa.amsl.com>; Wed, 12 Oct 2011 00:41:18 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4B21F8A6F for <softwires@ietf.org>; Wed, 12 Oct 2011 00:41:17 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSX00KB0Z9T8L@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 12 Oct 2011 15:25:05 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSX00BWVZ9TY3@szxga04-in.huawei.com> for softwires@ietf.org; Wed, 12 Oct 2011 15:25:05 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE60876; Wed, 12 Oct 2011 15:25:05 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 15:24:58 +0800
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.227]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 12 Oct 2011 15:24:58 +0800
Date: Wed, 12 Oct 2011 07:24:57 +0000
From: Leaf yeh <leaf.y.yeh@huawei.com>
In-reply-to: <77E5DB2B-70A2-4797-AE89-5D6A5D8E514F@gmail.com>
X-Originating-IP: [10.70.39.98]
To: Satoru Matsushima <satoru.matsushima@gmail.com>, Tetsuya Murakami <tetsuya@ipinfusion.com>
Message-id: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA05767E7E@SZXEML510-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
Thread-index: AQHMh0ClppljXMMUk0246OCDrJF2JZV2S26AgACkO2D//4ysgIABxLiA
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net> <16C872EF-F79E-4FD8-89B9-21B50129BA70@employees.org> <2118E521-F0CC-46F3-9F63-0EC6893326C6@laposte.net> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA0576663D@SZXEML510-MBS.china.huawei.com> <F0571321-3F33-49DE-9350-1060AEF1532F@gmail.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA05766BB8@SZXEML510-MBS.china.huawei.com> <77E5DB2B-70A2-4797-AE89-5D6A5D8E514F@gmail.com>
Cc: Softwires-wg <softwires@ietf.org>, "fine_sz@huawei.com" <fine_sz@huawei.com>
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
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, 12 Oct 2011 07:41:19 -0000

Satoru -> I think we could have it.
Tetsuya Murakami -> the decapsulation could be done for the packet having the tunnel end-point address as the destination or having the specific IPv6 prefix as the destination.

Does that mean BR needs to inject a route pointing to the BR subnet prefix, and using one interface address of BR as the next-hop of this prefix in the route? That means routes can direct the packets go to the right interface of the BR, right?


Best Regards,
Leaf


-----Original Message-----
From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] 
Sent: Tuesday, October 11, 2011 7:25 PM
To: Leaf yeh
Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg; fine_sz@huawei.com
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

On 2011/10/11, at 20:00, Leaf yeh wrote:

>> Remi - >> A Destination address from a CE to the outside IPv4 Internet is:
>>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
>>>> +--------------------------+----+---------------+------------+---+
>>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
>>>> +--------------------------+----+---------------+------------+---+
> Leaf -> In fact, I doubts we could have the same address mapping for both tunnel and translation. Supposed the address of tunnel end-points is preferred to be fixed, but the address for the translation could be variable.
> Satoru -> I think we could have it.
> 
> What is the definition of the IPv4 address in the above format? Is it the destination IPv4 address of any hosts outside 4rd IPv4 domain in the internet?

I believe that the embedded IPv4 address should be an IPv4 address of a host on outside the domain.

cheers,
--satoru

> 
> 
> Best Regards,
> Leaf
> 
> 
> -----Original Message-----
> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] 
> Sent: Tuesday, October 11, 2011 4:30 PM
> To: Leaf yeh
> Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg; fine_sz@huawei.com
> Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
> 
> Leaf, thanks for the summary.
> 
> On 2011/10/10, at 20:34, Leaf yeh wrote:
> 
>> Remi - >> a1- If the CE has an exclusive or shared IPv4 address:
>>>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>>> | IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
>>>> +-------------+--------+---+---+----------------+------+-----+---+
>> Ole - > putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support. > what's the L?
>> Remi - Don't see what you found unclear.
>> 
>> 
>> Question: Supposed the question is on the last field, named 'L', in the new address format.
>> 
> 
> Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix can't be self delimiting to extract IPv4 address and port-set ID in the case of double translation. That's my understanding. Is that correct?
> As '4rd-a', and 4via6(draft-murakami-softwire-4v6-translation), the 'L' bits are not necessary because 'CE IPv6 prefix length' is defined through a domain, instead of 'L'.
> 
> 
>> 
>> Remi - >> A Destination address from a CE to the outside IPv4 Internet is:
>>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
>>>> +--------------------------+----+---------------+------------+---+
>>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
>>>> +--------------------------+----+---------------+------------+---+
>> Ole - this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.
>> Remi - Copying an available IPv4 address at a fixed place isn't IMHO a "big change".
>> 
>> 
>> Concern: Supposed the replacement of the 1st 64bits of the BR address with a subnet prefix is not for the tunnel case if the field of IPv4 address can be variable, right?
> 
> I think that it could be a case where the BR address with a subnet prefix for the tunnel case. My concern rather than the BR address is that a CE should pick packets up which have 'V' in IID, even destined prefixes are delegated to nodes which are behind of the CE.
> 
> 
>> 
>> In fact, I doubts we could have the same address mapping for both tunnel and translation. Supposed the address of tunnel end-points is preferred to be fixed, but the address for the translation could be variable.
>> 
> 
> I think we could have it.
> 
> cheers,
> --satoru
> 
> 
>> 
>> Best Regards,
>> Leaf
>> 
>> 
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Rémi Després
>> Sent: Thursday, October 06, 2011 6:07 PM
>> To: Ole Troan
>> Cc: Softwires-wg
>> Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
>> 
>> 
>> Le 6 oct. 2011 à 18:47, Ole Troan a écrit :
>> 
>>> Remi,
>>> 
>>> [...]
>>> 
>>>> 2.
>>>> (a)
>>>> The IPv6 Source address of an IPv4 packet from a CE is:
>>>> 
>>>> a1- If the CE has an exclusive or shared IPv4 address:
>>>> 
>>>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>>> | IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
>>>> +-------------+--------+---+---+----------------+------+-----+---+
>>> 
>>> putting the IPv4 address / port information at the end of the interface identifier will allow for > /64 support.
>> 
>> Could you explain more the requirement you have in mind?  
>> 
>>> what's the L?
>> 
>> On the picture, L is 32 bits + Length(PSID).
>> Don't see what you found unclear. 
>> 
>>> 
>>> you suggest that the first subnet of an allocation should be used for this purpose.
>> 
>> Did I do this?
>> Please explain because that's not, IMHO,  something to be done.
>> 
>>> the first subnet is convenient to use for e.g. manual addressing (since it allows the :: short hand).
>>> I do wonder if this has to be provisioned. e.g. some deployments may use the first subnet for the link between
>>> CE and PE. (i.e. a /56 - 1 using the PD exclude option is used).
>> 
>> See just above.
>> 
>>> 
>>>> a2- If the CE has an IPv4 prefix:
>>>> 
>>>> <--------- 64 ------------><8 ><-- L < 32 --><--- 48-L -----><8 >
>>>> +-------------+--------+---+---+-------------+---------------+---+
>>>> | IPv6 prefix |CE index| 0 | V | IPv4 prefix |         0     | L |
>>>> +-------------+--------+---+---+-------------+---------------+---+
>>>> 
>>>> (b)
>>>> V is the mark that characterizes IPv6 packets that are in reality IPv4 packets.
>>>> Its value differs from any permitted value of this octet in IPv6 IIDs  (ref RFC 4291).
>>>> 
>>>> It is understood that, if double Translation coexists with single translation, concerned ISPs may notify their CEs to use the U octet of RFC 6052 instead of V.
>>>> 
>>>> An unambiguous mark is fortunately possible because currently permitted IIDs have in their first octet either bit6 = 0 (the "u" bit"), or bit6 = 1 and bit7= 0 (the "g" bit).
>>>> With V having "u" = 1 (signifying Universal scope) AND "g" = 1, distinction is therefore deterministic.
>>>> 
>>>> The proposed V is = 00000011. 
>>>> (With other values of this octet, other IID formats can be defined in case some would be useful in the future.)
>>>> 
>>>> Note that, if and when a consensus is reached in Softwire, an extension of RFC 4291 will have to be submitted to 6MAN. 
>>> 
>>> or rather IEEE?
>> 
>> IMHO, IEEE has nothing to do with a marker that is purposely an escape mechanism from the modified EUI-64 format of RFC 4291.
>> 
>>> I am not convinced that "V" is needed.
>> 
>> The point is more, IMHO, whether you have an objection to it (and in this case which one).
>> Reason is that we are working for a consensus, and several are satisfied with the explanation that there are use cases where it is useful, and none where it is harmful.
>> 
>>> you could even use the IANA OUI if pretty printing was required.
>> 
>> The point is that it takes 32 bits which is too much to have IPv4 address + PSID in the IID.
>> 
>> 
>>>> (c)                                   
>>>> A Destination address from a CE to the outside IPv4 Internet is:
>>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
>>>> +--------------------------+----+---------------+------------+---+
>>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
>>>> +--------------------------+----+---------------+------------+---+
>>> 
>>> this is a big change for encapsulation, where prior to this encapsulation means sending to a single destination.
>> 
>> Copying an available IPv4 address at a fixed place isn't IMHO a "big change".
>> 
>>> if we also allow for a BR subnet prefix of /128 I'm OK with this (I think).
>> 
>> I don't understand what you mean by "Subnet prefix of /128".
>> 
>> 
>>>> Note that if double-translation CEs are notified to use U instead of V, the last octet becomes 0 per RFC  6052.
>>> 
>>> how would a CE know if it was single or double translating?
>> 
>> Presumably with a usual method, e.g. DHCPv6.
>> Anything problematic with that?
>> 
>> 
>>> e.g we could do:
>>> 
>>> <--------- 64 ------------><--- 24 ------><----- 32 -------><--8 >
>>> +-------------+--------+---+--------------------+------+-----+---+
>>> | IPv6 prefix |CE index| S | 00-00-5E    |  IPv4 address  | PSID |
>>> +-------------+--------+---+---+----------------+------+-----+---+
>>> 
>>> we also need to handle the case where IPv6 prefix + CE index > 64.
>> 
>> Please explain more your understanding of this requirement.
>> (I personally believe we should avoid that.)
>> 
>>> I suggest we then just put as much as the interface identifier that will fit.
>> 
>> 
>> May I suggest that, to be more constructive, you could first express your objections to the proposed unified mapping, rather than making a number of new proposals whose justifications are sometimes hard to understand, 
>> 
>> Cheers,
>> RD 
>> 
>> 
>>> 
>>> cheers,
>>> Ole
>>> 
>>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>