Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Maoke <fibrib@gmail.com> Mon, 12 March 2012 02:08 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 3DE4A21F85D7 for <softwires@ietfa.amsl.com>; Sun, 11 Mar 2012 19:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.879
X-Spam-Level:
X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, 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 a-MHShQsmlLP for <softwires@ietfa.amsl.com>; Sun, 11 Mar 2012 19:08:15 -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 AE01021F8513 for <softwires@ietf.org>; Sun, 11 Mar 2012 19:08:14 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2360403ghb.31 for <softwires@ietf.org>; Sun, 11 Mar 2012 19:08:14 -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=p0JlJhSFfeaHbi8Gh9aO1x0BFUTMzqQdAniy5wxntDM=; b=eCMindQJvOdlZ03htnuSrzAsF03g5QCQdHwzqpXq0LeDns9S1bzkx8IdwPxZe5AJ5M nx1nP49qJzcDNPGmM5Q2ufuuRjWbf4RJN0wxqwcuCgBLjaPeBZc8CrfzjgUfOguClFo0 hVFhy9wtgfm4AgcZ0EdTodS3hF4v6xCFdUi9JjXjgOgT8FC27xmVoerHk+IwtN67lG6I xEsdfJ7SIkSolCAuDN+HcVr32rqxO5TkxMwheBeEM/+vpS4VCrY+jLklzYyDk4CiEyzd aimUUiTOz23WBZR7b5G95vS/7lDQ49XmiZf93FhwMldI+3Dg4HgTQxb3lgIAsULt82Vf NZdg==
MIME-Version: 1.0
Received: by 10.229.134.196 with SMTP id k4mr1977251qct.29.1331518094122; Sun, 11 Mar 2012 19:08:14 -0700 (PDT)
Received: by 10.229.98.21 with HTTP; Sun, 11 Mar 2012 19:08:14 -0700 (PDT)
In-Reply-To: <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net>
References: <B509CB1C-4A0A-408B-9B4A-C0F847169431@juniper.net> <2AB8570A-644F-4792-8C56-44AD80A79234@laposte.net> <D6428903-FBA0-419C-A37F-A00874F28118@laposte.net> <CAM+vMERsVz7cuC1C52gw12wySaEgw8=44JjS8AUygj0vJ899Cg@mail.gmail.com> <DDD20574-4ECD-4285-BB15-548628FB0425@laposte.net> <CAM+vMETahum9rB+fr=OHAmVobDZSzRRy9mUwkjryhqRvaJWe-Q@mail.gmail.com> <35065EB3-D4D6-451B-ACED-67BB94C77F18@laposte.net> <CAAuHL_D68nkd36ifLzEeVR67Q124VH-pMhM1pkEE_PcLbGxBrw@mail.gmail.com> <14D90642-0478-4AB9-91AA-A3E0310197F2@laposte.net> <CAFUBMqX9dj8MSeZdJTic5iOT=Jjg4oihWs30FWVAca08v_3=7g@mail.gmail.com> <D476AFD2-3B6B-48A0-971D-C65CC2CFA46B@laposte.net> <CAFUBMqU1wtP5prSaLG8hDSuv-EGWP5Diqoj6WEMHb_q8hNVDdQ@mail.gmail.com> <4BA560D3-5D48-4911-BDCB-D9CB490FBBA1@laposte.net>
Date: Mon, 12 Mar 2012 11:08:14 +0900
Message-ID: <CAFUBMqVzbtZ7JxunHv7m1zgWjRa2sh7zZS+91aURAy8-xTZW8g@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary="00248c6a86e203213504bb0237dd"
Cc: Softwires WG <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
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: Mon, 12 Mar 2012 02:08:17 -0000
2012/3/9 Rémi Després <despres.remi@laposte.net> > Maoke, > Thanks for the detailed question. > Clarification below. > > > 2012-03-09 12:04, Maoke : > > 2012/3/9 Rémi Després <despres.remi@laposte.net> > >> Thanks Maoke for the opportunity to clarify some of the points below. >> >> >> 2012-03-09 03:14, Maoke: >> >> hi Remi, >> >> sorry but i follow this late. something not clear to me, according to our >> earlier discussions. >> >> 2012/3/8 Rémi Després <despres.remi@laposte.net> >> >>> >>> Le 2012-03-08 à 03:47, Washam Fan a écrit : >>> >>> > Hi Remi, >>> > >>> >>>>> Secondly, -04 added NAT64+ parts. >>> >>>>> If I understood correctly, there are no additional requirements >>> for NAT64 >>> >>>>> boxes. >>> >>>> >>> >>>> Well, NAT64 boxes remain what they are. >>> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 >>> although it >>> >>>> has a dual stack. >>> >>>> >>> >>>> But the advantage of 4rd tunneling over RFC6145 double translation >>> is better >>> >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols >>> that may >>> >>>> use the TCP checksum algorithms) >>> >> >> to clarify my understanding: >> 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the >> DF=1/MF=1 cases >> 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message >> directly as IPv6 payload is a wise idea. lack of address consistency >> ensurance mechanism (i.e. no header checksum in IPv6 header no >> pseudo-header checksum in ICMPv4 message) >> >> >> The 4rd ICMPv4 error message has as only purpose to be delivered to a >> 4rd-aware node. There, it will be treated as an ICMPv4 error. >> It is assumed that no DPI in some middle box will need to interpret >> ICMPv4 error messages. >> >> 3. for the "future protocols", i remember our earlier discussion >> concluded that CNP can free the code change with ALREADY KNOWN >> tcp-checksumed protocols. am i wrong here? >> >> >> I think you are. As the 4rd-u-04 says (sec 4.4): >> "NOTE: This guarantees that, for all protocols that use the same checksum >> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this >> independently from where the checksum field is placed for each protocol. >> Today, such protocols are UDP [RFC0768], TCP [RFC0793], >> UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, BRs >> will support them without needing an update." >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > exactly here it is the point of disagreement. here the "update" refers to > implementation, right? then what is the BR's logic? > > > A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) { > calculate IPv6 address for dst, taking the port from > L4_proto.header; > /* do nothing with checksum, CNP applied for the LIST */ > } else { > discard; > } > > > No. R-7 (3) isn't ambiguous about this. > > > B. if (1) { > calculate MAP IPv6 address for dst, supposing dst port is always > there; > /* do nothing with checksum suppose CNP applied to all protocols */ > } > > > Yes, as specified in R-7 (3). > > As a matter of fact, it doesn't "suppose dst port is always there". > It just takes bits that are the right ones if dst port (or ICMPv4 ID) is > present, unless a source has, by mistake, sent a port-less packet to a > shared IPv4 address. > What happens in this mistake case is detailed below. > > > if you refer to logic B, the "BR will support them without needing an > update" is true. > > > Right. > > however, the risk is should new ones specified but not having the tcp-like > layout or the tcp-checksum may fail to become a valid IPv6 packet and > (because of the layout difference) it is possible that the destination IPv6 > address is wrong. > > > If a source sends to a shared IPv4 address with a port-less protocol, it > will receive a "destination unreachable" ICMPv4 packet. > Its code will be either "network unreachable", because no CE had the > derived IPv6 address (sec. 4.7), or "protocol unreachable", because the > reached CE NAT44 cannot process this port-less protocol. > The usual error-signalling mechanism works as it has to. > > ok. now i got the whole picture. sorry for the late understanding. but does this means 4rd-U is an extension of NAT44 or at least depends upon NAT44? RFC6145 has no such dependence at all. - maoke > > > if you refer to logic A, the BR must be updated whenever any new protocol > is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic, > when applied with MAP, is: > A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) { > calculate IPv6 address for dst, taking the port (or equivalent field > when ICMP) from Payload_Proto.header; > recalculate the checksum in Payload_Proto.header; > } else { > discard; > } > > > both A and A' has no risk as B has. > > > See above why B has no operational risk. > > Thanks, > RD > > > > > > > >> >> >>>> For an ISP to extend this advantage to its stateful NAT64, it need >>> to be 4rd >>> >>>> aware (become a NAT64+). >>> >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address >>> (with a V >>> >>>> octet instead of a "u" octet), use the 4rd header mapping instead >>> of RFC6145 >>> >>>> translation. >>> >> >> questions: 1. NAT64+ here refers to stateful case only, right? >> >> >> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make >> decision between 4rd-U pseudo-encapsulation (let me use this term because >> i argue it does not conform to the behavior of encapsulation) and NAT64 >> translation? (as we have neither V nor U in the IPv4 addresses). >> >> >> a) Note that there is no claim that 4rd-u would be an encapsulation >> solution (it isn't!). What is claimed is that it is a transparent-tunnel >> solution (same IPv4 packet received by destinations as sent by sources, >> except for TTL which progress, and for ECNs that may be changed if >> congestion is met between source and destination). >> > > yes. TTL is progressing as if it were in translation. ECN is another > topic: it changes even in the encapsulation. > > >> >> b) In draft -04, R-7 (8) says: >> "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST >> derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): >> take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 >> address; append the CNP. >> >> <----------- Rule IPv6 prefix --------->: >> +-------------------------------+---+---+-------------+------+ >> | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | >> +-------------------------------+---+---+-------------+------+ >> : 64 : 8 : 8 : 32 : 16 : >> >> Figure 6 " >> >> what do you mean with the unspecified IPv4 address*es*? isn't it only the > 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block? > > reading your example in 5.1, i understand your point: the above picture > describes the mapping for the source address if the packet is sent to the > IPv6 world through BR but without the inverse-header-mapping. in this case > the U-octet is applied and the CE-delegated prefix plays also the role of > NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if i'm > right, it is clear. > > but i haven't seen the necessity of defining the V-octet here. with the V, > BR seeing the V does the header mapping while seeing the U does nothing but > only the regular routing. without the V, BR seeing the CE-delegated /64 > does the header mapping while seeing another prefix (no matter how long the > length is) does nothing but only the regular routing. > > the V-attached stuff in fact makes another, more-specific prefix under the > delegated prefix of a CE. > >> >>> >>> >>> I perfer to leave NAT64 out of scope. >>> >> >>> >> NAT64 as is remains out of scope. >>> >> What is in scope is only the possibility to improve IPv4 transparency >>> of NAT64 nodes by using transparent tunneling, instead of double >>> translation, when reached by 4rd CEs (making them NAT64+ nodes). >>> > >>> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a >>> > new term NAT64+ invented? >>> >>> >>> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 >>> needs to be upgraded to replace RFC5145 translation by header mapping when >>> IPv6 addresses it deals with are 4rd addresses (have the V octet). >>> >> confused. how does NAT64+ happens at BR? without the V octet, NAT64 needs > not to be upgraded at all. > >> >>> >>> > >>> >> This new capability, introduced in -04, is derived from the 464XLAT >>> proposal. >>> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only >>> networks can communicate via NAT64s, but IPv4 transparency has limitations >>> which can be eliminated by upgrading NAT64s to NAT64+ status (a backward >>> compatible evolution). >>> >> >>> > >>> > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? >>> >>> To take advantage, for customers that are 4rd capable, of better IPv4 >>> transparency than with double translation, the NAT64 MUST be upgraded. >>> >> > Remi didn't answer this question of Washam. 4rd-U keeps only stateful > NAT64 as it is at CE, to my understanding. > > >> >> may i add that it (4rd-U) provides better IPv4 transparency than double >> translation but less simplicity in the term of layering architecture than >> encapsulation? (here i avoid sticking things on my understanding to >> "transparency"). personally i don't think transparency is the most >> important reason that generally operators prefer encapsulation rather than >> translation. simplicity and clear concept in architecture is the reason. no >> matter how much we keep IPv4 information unchanged across the IPv6 domain, >> as long as the IPv4 header is destroyed, it is a solution of "translation" >> rather than of "encapsulation". >> >> >> Different view here. >> a) Ole had a nice slide in the interim meeting about how double >> translation tends to break transparency. I use "reversible header mapping" >> which I find intuitive, or just "header mapping", but "reversible header >> translation" could be OK. >> A key difference, is that payloads are transparently tunneled in 4rd >> while they are processed, with dependence of upper layer protocols in >> double translation. This is AFAIK an important difference. (To take an >> example, RFC6145 requires to discard UDP-lite packets (RFC3828) while they >> are tunneled with 4rd) >> > > where is it stated in RFC6145 that it requires to DISCARD UDP-lite > packets? > > >> >> b) As said in Sec 1 of draft -04: >> " While IPv6 headers are too long to be mapped into IPv4 headers, so >> that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4 >> headers can be reversibly mapped into IPv6 headers so that 4rd tunnel >> packets can be designed to be valid IPv6 packets, thus ensuring >> compatibility with IPv6-only middle boxes that perform >> deep-packet-inspection." >> I see no real complexity in noting that IPv4 headers are small enough to >> be reversibly mapped in IPv6 headers. >> > > our terminologies are biased. i emphasize the simplicity is in the term of > architecture. encapsulation is a widely used concept in the networking, > making one protocol as an underlay of another. we may have a packet with > all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but > re-ordered and re-organized, into, e.g., a super L2-U. it is surely a > reversible header mapping but we can't say that of either encapsulation or > the (narrow-sense) tunneling. this is my point. from the operator's view, > once it is not the simple layered encapsulation, i cannot see it as a > substitute for the encapsulation, but see it as a substitute of other > translations, if i see this is a more gentle translation than others and > this gentleness costs little. > > >> Of course this still requires careful technical verification, but once >> done, it's done once and for all. >> >> i don't incline to use the term "tunneling" since tunnel could have a >> variety of forms, among which encapsulation is one but not the only one. >> >> >> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation >> tunnels. >> > > well, in general sense "tunnel" means a source route essentially (RFC1241 > made a very good summary about variety of tunnels). to such extent, RFC6145 > makes *translation tunnels* (in general sense of the term "source route"). > but we never call it like that, because, when most people are talking about > "tunnel" today, we refers to the narrow sense "tunnel", which means the > encapsulation. it is fine that 4rd-U call itself as a tunnel solution but > it should be pointed out that this is a tunnel in the general sense. > > therefore i emphasize that, maybe too academic, the counterpart of > translation is encapsulation but not the "tunneling". in the architecture, > we have either the building block of making an underlay protocol as a > virtual link or the building block of making another protocol as a > participant in the path of end-to-end delivery. although you argued this is > *ONLY* the understanding of some diffserv guys, i don't think this > understanding is not generic. > > for the simplicity in operation, we often think in such a way: if we would > like to hide the underlay and make a protocol as an underlay or we would > like to expose the things out. both have their use cases. if 4rd-U is said > it fills some important gaps between the two, it would be great. if 4rd-U > is said it replaces the both, i doubt it can. once we want to make a stuff > having advantage of this and that, we often make out a stuff also having > disadvantage of both. for me, i prefer if 4rd-U is moderately defined with > specific use-case and fully description on its pros/cons, > features/limitations, approaches/tradeoffs. > > cheers, > maoke > > >> >> >> Cheers, >> RD >> >> >> >> >> >> cheers, >> maoke >> >> >>> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only >>> hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue to >>> use the NAT64+ as an ordinary NAT64. >>> >>> Regards, >>> RD >>> >>> > >>> > Thanks, >>> > washam >>> >>> Such transparency could be achieved by whther to add fragmentation >>> header. >>> >>> Anyway, let's hear some comments from the group >>> >> >>> >> OK >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> > >
- [Softwires] Call for agenda items Durand, Alain
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Templin, Fred L
- Re: [Softwires] Call for agenda items Mingwei Xu
- Re: [Softwires] Call for agenda items Sheng Jiang
- [Softwires] Call for agenda items Alain Durand
- Re: [Softwires] Call for agenda items mohamed.boucadair
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Mingwei Xu
- Re: [Softwires] Call for agenda items Yiu L. Lee
- Re: [Softwires] Call for agenda items Templin, Fred L
- Re: [Softwires] Call for agenda items Templin, Fred L
- Re: [Softwires] Call for agenda items Mingwei Xu
- Re: [Softwires] Call for agenda items Jacni Qin
- Re: [Softwires] Call for agenda items Tina Tsou
- Re: [Softwires] Call for agenda items Sheng Jiang
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] Call for agenda items Tomasz Mrugalski
- Re: [Softwires] Call for agenda items Eleven Fu(Yu)
- Re: [Softwires] Call for agenda items GangChen
- [Softwires] Call for agenda items Alain Durand
- Re: [Softwires] Call for agenda items Xing Li
- Re: [Softwires] Call for agenda items Jacni Qin
- Re: [Softwires] Call for agenda items xiaohong.deng
- Re: [Softwires] Call for agenda items Reinaldo Penno
- Re: [Softwires] Call for agenda items Tetsuya Murakami
- Re: [Softwires] Call for agenda items GangChen
- Re: [Softwires] Call for agenda items Ole Troan
- Re: [Softwires] Call for agenda items GangChen
- Re: [Softwires] Call for agenda items Shishio Tsuchiya
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Qiong
- [Softwires] Call for agenda items Alain Durand
- Re: [Softwires] Call for agenda items Ole Trøan
- Re: [Softwires] Call for agenda items Sheng Jiang
- Re: [Softwires] Call for agenda items Rémi Després
- Re: [Softwires] Call for agenda items Shishio Tsuchiya
- Re: [Softwires] Call for agenda items Behcet Sarikaya
- Re: [Softwires] Call for agenda items Qiong
- [Softwires] IPv4 Residual Deployment - Unified-st… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Behcet Sarikaya
- Re: [Softwires] Call for agenda items Naoki Matsuhira
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… GangChen
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] Call for agenda items Peng Wu
- Re: [Softwires] IPv4 Residual Deployment - Unifie… GangChen
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Washam Fan
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] Call for agenda items Naoki Matsuhira
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Lee, Yiu
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] IPv4 Residual Deployment - Unifie… Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Maoke
- Re: [Softwires] Call for agenda items Naoki Matsuhira
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després
- Re: [Softwires] 4rd-u tunnels and stateful NAT64s Rémi Després