Woj, I did attend the softwire Beijing interim meeting. What I heard then were two conflicting arguments a) the ACL should be accomplished via IPv6 plane. b) full IPv4 address should be encoded in the IPv6 address, so that data filtering could be achieved.
Although these have been discussed on the mailing list for long, I only witness one operator stating this is an issue since then. Best regards, Zhen On Mon, Sep 10, 2012 at 9:54 PM, Wojciech Dec <[email protected]> wrote: > Zhen, > > you perhaps may be missing out on the last 1+ years of discussions in this > WG regarding the role/purpose of NAT464 technology and all relevant > architectures, including the softwire Beijing interim with map-t use-cases, > the WG adoption vote/status, discussion on xlat464, as well as 4rd-u > (although the need for this technology variant remains questionable). > While we can re-hash many of those, in the interest of moving forward it > would be helpful if you revisited the archives to find the answers. > > Regards, > W. Dec > > > > On 8 September 2012 17:03, Zhen Cao <[email protected]> wrote: >> >> Hello Roberta, >> >> For most operators, I haven't heard the issues existed. If those use >> cases are just designed for this solution, this does not convince >> anybody including me, and we do not need to discuss a scenario which >> is to justify a solution. >> >> What's your unique network architecture compared with others, can you >> show us your concrete network architecture? What's your deployment >> plan for MAP-T and where? >> >> Thanks >> Zhen >> >> On Fri, Sep 7, 2012 at 5:03 PM, Maglione Roberta >> <[email protected]> wrote: >> > Hello Gang, >> > I do see some difference between MAP-E and MAP-T regarding the >> > application of ACL. >> > Let's consider the following scenarios: >> > - when a destination is outside of the MAP domain in case of MAP-E the >> > CE uses as IPv6 destination the IPv6 address of the MAP BR while for MAP-T >> > it uses the IPv4 address of the destination mapped in IPv6 by using the MAP >> > IPv6 rule. If I need to apply an ACL that matches a destination outside of >> > the map domain I can only do that by using MAP-T; >> > - another example is how to apply an ACL that matches UDP or TCP packets >> > on the BNG. My understanding is that this cannot be achieved with MAP-E, as >> > the IPv4 packet is encapsulated in IPv6. >> > >> > These are just a couple of examples about ACL, there are use cases with >> > operational implications, that can be simply addressed by MAP-T. >> > >> > Thanks >> > Best regards, >> > Roberta >> > >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] On >> > Behalf Of GangChen >> > Sent: venerdì 7 settembre 2012 8.05 >> > To: softwires >> > Subject: [Softwires] Is ACL really a point to drive MAP-T solution? >> > >> > Hello all, >> > >> > As I identified, there is no issue to apply ACL either on fix networks >> > or mobile networks. Why most operators don't have issue, why there is >> > the issue for special operator. What is the issue? >> > >> > MAP-T and MAP-E have same address format. And, we have a good decision >> > to standard the MAP-E solution. >> > >> > Even ACL is needed, MAP-E is sufficient. There is no need to create >> > another flavor >> > >> > Considering above, MAP-T is superfluous. >> > I don't think we need spend much energy on that. >> > If there is something I missed, please kindly identify it before >> > submitting the MAP-T document. >> > >> > Many thanks >> > >> > Gang >> > _______________________________________________ >> > Softwires mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/softwires >> > >> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> > persone indicate. La diffusione, copia o qualsiasi altra azione derivante >> > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora >> > abbiate ricevuto questo documento per errore siete cortesemente pregati di >> > darne immediata comunicazione al mittente e di provvedere alla sua >> > distruzione, Grazie. >> > >> > This e-mail and any attachments is confidential and may contain >> > privileged information intended for the addressee(s) only. Dissemination, >> > copying, printing or use by anybody else is unauthorised. If you are not >> > the >> > intended recipient, please delete this message and any attachments and >> > advise the sender by return e-mail, Thanks. >> > >> > _______________________________________________ >> > Softwires mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
