Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
Satoru Matsushima <satoru.matsushima@gmail.com> Tue, 11 October 2011 08:30 UTC
Return-Path: <satoru.matsushima@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 7336B21F8B4A for <softwires@ietfa.amsl.com>; Tue, 11 Oct 2011 01:30:54 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33a+G67V5kJK for <softwires@ietfa.amsl.com>; Tue, 11 Oct 2011 01:30:53 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3410321F84B6 for <softwires@ietf.org>; Tue, 11 Oct 2011 01:30:34 -0700 (PDT)
Received: by gyd12 with SMTP id 12so7692945gyd.31 for <softwires@ietf.org>; Tue, 11 Oct 2011 01:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dvsjOaM5Y/AZxWpEX9urjvF3Q4JkmsxMp7ODf+Bo+lc=; b=tKd+3+ZqA7xLjN0BoBAdJxcA59Tt6wrqguuYzvRUHUFPDN8iL2JBmDBjnW2y3jnHLu sivQkvdubLr4y8CgReAGEF59Gf7XWmU6XU8Xp3m8tJyP/A0G7NSIp3o53hqLyTQb66d6 W/Cp13waOlKccQTIElem0jT6Tn4XaRHcF8/IY=
Received: by 10.68.2.163 with SMTP id 3mr2794239pbv.25.1318321832570; Tue, 11 Oct 2011 01:30:32 -0700 (PDT)
Received: from [10.201.83.217] ([202.45.12.174]) by mx.google.com with ESMTPS id h5sm76877410pbq.11.2011.10.11.01.30.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 01:30:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="utf-8"
From: Satoru Matsushima <satoru.matsushima@gmail.com>
In-Reply-To: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA0576663D@SZXEML510-MBS.china.huawei.com>
Date: Tue, 11 Oct 2011 17:30:25 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0571321-3F33-49DE-9350-1060AEF1532F@gmail.com>
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>
To: Leaf yeh <leaf.y.yeh@huawei.com>
X-Mailer: Apple Mail (2.1244.3)
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: Tue, 11 Oct 2011 08:30:54 -0000
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
- [Softwires] Proposed Unified Address Mapping for … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Congxiao Bao
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Congxiao Bao
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Congxiao Bao
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … xiaohong deng
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Zhen Cao
- Re: [Softwires] Proposed Unified Address Mapping … Zhen Cao
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … liu dapeng
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Tetsuya Murakami
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Tetsuya Murakami
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Internal routing based on the V o… Rémi Després
- Re: [Softwires] Internal routing based on the V o… Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després