Re: [Softwires] Comments on 4rd-u-04
Maoke <fibrib@gmail.com> Tue, 13 March 2012 00:59 UTC
Return-Path: <fibrib@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 D19E511E8072 for <softwires@ietfa.amsl.com>; Mon, 12 Mar 2012 17:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.175
X-Spam-Level:
X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 kWsRXlBzFA4u for <softwires@ietfa.amsl.com>; Mon, 12 Mar 2012 17:59:45 -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 1A9FE11E8079 for <softwires@ietf.org>; Mon, 12 Mar 2012 17:59:45 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so3680028ghb.31 for <softwires@ietf.org>; Mon, 12 Mar 2012 17:59:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zOHPPF2lRDC59vQBcML5njG5yhmCAIQ4DMvJT2W5YDE=; b=FIh3j8Ye7lslXYd0G6radH8PX1Ubr+S5t/AFV+Od8pA5vG0shhfT6aDI7xcYbiYXxz XBkStu7ThQBUBAbyD1MV4RFUenBG0RJ7xBgwtmw9ifd4owwVQ5B2WaYCgkAfr3yUx/8O dxbzqD7HiOiS6Pn4R5OAioPojraTMKHRxBg5sxleBY2lNY3k8m9rV3cwLWvk29U0hAiF VisKgErBRWXsxy4VxPbDXYtrz03ZudMnJVR2c8v9ZVrCtHli+4Ri5FRJmBPlKD3/lVef kCEKZHUnmD3lXq6P86MVJDDUuP3utzkz9Sl+0Dh300ZnS1sD92V1lK1KxTtCERYq0KUA 05ew==
MIME-Version: 1.0
Received: by 10.229.136.200 with SMTP id s8mr3272046qct.9.1331600384595; Mon, 12 Mar 2012 17:59:44 -0700 (PDT)
Received: by 10.229.98.21 with HTTP; Mon, 12 Mar 2012 17:59:44 -0700 (PDT)
In-Reply-To: <62F71361-3110-4069-B186-915003CD986B@laposte.net>
References: <CAAuHL_CXKw-D=8a-9d-Wmqt9nP69sUwbZoqfQ=Q=QrKskrPeHQ@mail.gmail.com> <48EF44A9-F13E-4987-946E-B4E6EC18D166@laposte.net> <CAFUBMqWxkG2w59eQZCs60jVdpGWbmBRzrCzyqN1tSfDGW-L6fw@mail.gmail.com> <62F71361-3110-4069-B186-915003CD986B@laposte.net>
Date: Tue, 13 Mar 2012 00:59:44 +0000
Message-ID: <CAFUBMqXXv05P3s971bAy0VtJ1NmBOSUjgq6f3EGD9JOEeT792A@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="002354530350e8191f04bb155f66"
Cc: Softwires <softwires@ietf.org>
Subject: Re: [Softwires] Comments on 4rd-u-04
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, 13 Mar 2012 00:59:46 -0000
hi Remi, 2012/3/12 Rémi Després <despres.remi@laposte.net> > Maoke, > > 1. > What you call the cost of "IANA authority on the use of V-bit" is neither > a development nor an operational cost. Once standardization is done, the > cost becomes 0. > exactly. > > 2. > Isn't it true that MAP addresses must have the "u" octet, i.e. 0x00, in > address bits 64-71? > If yes, MAP example addresses you give with 0x02 or 0x03 instead of "u", > aren't AFAIK valid MAP addresses. > oh, yes! i made the typo, falling into the EUI-64 case. MAP cites RFC6052 format for IID, while the latter states: "Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero." thanks a lot for pointing out the mistake! the corresponding example should be corrected as: #1. shared ipv4 address take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, PSID=8. MAP (without V-octet): native IPv6: 2001:db8:1234:5678::/64 mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:0000/128 (as a more-specific) cost: almost none. #2. exclusive ipv4 address 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 MAP (without V-octet): native IPv6: 2001:db8:1234:5670::/60 mapped IPv6: 2001:db8:1234:5670:00ab:cde5:6700:0000/128 (as a more-specific) cost: almost none. #3. exclusive ipv4 subnet 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f MAP (without V-octet): native IPv6: 2001:db8:1234:5600::/56 mapped IPv6: 2001:db8:1234:5600:00ab:cde5:6000:0000/128 (as a more-specific) 2001:db8:1234:5610:00ab:cde5:6100:0000/128 (as a more-specific) ... 2001:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a more-specific) > If no, please explain what I missed. > thanks a lot! > > 3. > You say that aggregation doesn't make sense in 4rd-u, e.g. with the > following example: > - native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit > - mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit > But the right choice for the second line is: > - mapped IPv6: 2001:db8:1234:5670:3000::/72 > 2001:db8:1234:5670:0300::/72, right? ;-) > Thus, longest match does the job. > > exactly. however, my point is: as the longest-match can do the job with V octet or without it, why don't we directly use the version without it? - maoke > (What you describe is what might have applied if we had kept the maxPsid > feature. But, as you may recall, we abandoned it unanimously in Taipei.) > > Cheers, > RD > > > Le 2012-03-12 à 11:51, Maoke a écrit : > > > > 2012/3/12 Rémi Després <despres.remi@laposte.net> > >> Hi, Washam, >> >> Thanks for your detailed questions and comments. >> Answers and further comments in line. >> >> Le 2012-03-11 à 10:48, Washam Fan a écrit : >> >> > Hi, >> > >> > Eventually I get a chance to review this version and have some major >> > comments and questions as below. >> > >> > 1. Relationship with MAP, MAP-T, MAP-E. >> > I thought, MAP was expected to be a generic algorithm for stateless >> > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, >> > MAP would apply to MAP-T, MAP-E as well as 4rd-u. >> >> The point is that 4rd-u unifies not only the address format for -T and >> -E, but also the header format so that a single standard becomes sufficient. >> The 4rd-U technique for this was presented in Taipei, but it didn't >> arise interest in the MAP team. Design of 4rd-u had then to become >> autonomous. >> >> > But draft 4rd-u-04 >> > doesn't mention MAP draft. >> >> 4rd-u is proposed as an alternative to the 2-standards approach of MAP. >> It therefore needs only needs a historical reference to MAP, which is >> done in sec. 8. >> >> > And I see the mapping rules stuff in the >> > draft overlapped with MAP. Confused. >> > >> > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. >> > Would you mind expaund on what benefits 4rd-u can gain exclusively? >> > Ideally, there would be a seperate section or even a seperate draft >> > for such comparison. >> >> As announced, an update of draft-despres-softwire-stateless-analysis-tool >> will contain a comparison (now to be posted very soon). >> >> An earlier comparison table was available in >> http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html >> >> In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to >> use IPv6-only middle boxes for deep packet inspection and web caches; also, >> like MAP-E, it ensures full IPv4 transparency. >> >> >> > 2. NAT64+ stuff. >> > My understanding, NAT64+ would translate 4rd tunnel packet as well as >> > native IPv6 packet to IPv4 packet and vice verse. Right? >> >> If the NAT64 is stateful per session, yes, it does translation at layer 4. >> NAT64s that are stateless at this layer are however also possible. THis >> is independent from 4rd. >> >> > I don't know >> > what the CE delegated prefix in NAT64+ looks like. >> >> - The delegated prefix is any prefix up to /64 that doesn't match any CE >> prefix (R-6 of draft-04)) >> - The source of a CE to NAT64+ packet must have the V octet for NAT64+s >> to be able to distinguish 4rd packets from other IPv6 packets (def of >> NAT64+). >> - The format is then: >> +-----------------------+-------+---+-----------------+------+ >> | CE IPv6 prefix | 0 | V | 0 | CNP | >> +-----------------------+-------+---+-----------------+------+ >> : =< 64 : >= 0 : 8 : 40 : 16 : >> >> >> Yet, it should be clearer in the draft. >> Thanks for this (good) question. >> >> >> > Can the native IPv6 >> > and 4rd shared the same delegated prefix? >> >> Yes. (This is the purpose of the V octet) >> >> > may i compare the V-octet with the MAP strategy? > > #1. shared ipv4 address > take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 > address for the CE is 0xabcde567, PSID=8. > > 4rd-U (with V-octet): > native IPv6: 2001:db8:1234:5678:0200::/72 > mapped IPv6: 2001:db8:1234:5678:0300::/72 > cost: IANA authority on the use of V-bit. > > MAP (without V-octet): > native IPv6: 2001:db8:1234:5678::/64 > mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a > more-specific) > cost: almost none. > > #2. exclusive ipv4 address > 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 > > 4rd-U (with V-octet), now aggragation doesn't make sense: > native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit > mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit > cost: IANA authority on the use of V-bit; implementation cannot take the > logic of longest-match! > > MAP (without V-octet): > native IPv6: 2001:db8:1234:5670::/60 > mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a > more-specific) > cost: almost none. > > #3. exclusive ipv4 subnet > 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f > > 4rd-U (with V-octet), now aggragation doesn't make sense: > native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit > mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit > cost: IANA authority on the use of V-bit; implementation cannot take the > logic of longest-match! > > MAP (without V-octet): > native IPv6: 2001:db8:1234:5600::/56 > mapped IPv6: 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a > more-specific) > 2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a > more-specific) > ... > 2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a > more-specific) > cost: a number of more-specific to identify the mapped things; but it > won't leaked out beyond the CE. > > if the well-developed longest-match can work, why should we need another > mechanism? > > cheers, > maoke > > > >> > if Yes, how to distinguish >> > them? >> >> See above. >> >> > the figure 6 seems to me it was talking about destination IPv6 >> > address derivation. >> >> Right. >> >> >> > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support >> > harpinning between 4rd tunnel packet and native IPv6 packet? >> >> The only evolution of NAT64 to make it a NAT64+ is its use of tunneling >> instead of RFC6145 translation, for all IPv6 addresses that have the V >> octet. (No other behavior needs to be modified.) >> >> >> > Personally, I'd like NAT64+ removed from the draft. It might deserve a >> > seperate draft. >> > This way, it would make the draft more understanding >> > for readers who are new to 4rd-u. >> >> The specification has to explain conditions in which a CE can tunnel IPv4 >> packets although it has no assigned public IPv4 address, even shared. >> Explaining more what is NAT64+ is IMHO better than explaining less. >> >> >> > 3. Fragments. >> > The algorithm proposed in R-9, would have applied to generic NAT >> > generally. Why it is specific to 4rd BR? >> >> NATs may have to remember not only destination ports but also source >> ports. >> A similar algorithm could however apply to NAT64s, but this is off 4rd >> scope. >> >> >> > Anyway BR would keep fragment >> >> They MAY, but AFAIK don't need to if they use R-9 algorithm. >> >> > state somehow and anycase BR facing IPv4 Internet would be impossible. >> >> In the CE to BR direction, destinations are full IPv4 addresses so that >> each fragment can be individually forwarded. >> Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that >> no port-based check is needed to ensure that no CE can spoof fragments >> from another CE. >> >> >> Regards, >> RD >> >> >> >> > >> > Thanks, >> > washam >> > _______________________________________________ >> > 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] Comments on 4rd-u-04 Washam Fan
- Re: [Softwires] Comments on 4rd-u-04 Rémi Després
- Re: [Softwires] Comments on 4rd-u-04 Washam Fan
- Re: [Softwires] Comments on 4rd-u-04 Maoke
- Re: [Softwires] Comments on 4rd-u-04 Rémi Després
- Re: [Softwires] Comments on 4rd-u-04 Maoke
- Re: [Softwires] Comments on 4rd-u-04 Rémi Després