
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">For the record, we are asking similar questions about 464XLAT in v6ops. If you are deploying it, please advise <font color="#007aff"><span style="caret-color: rgb(0, 122, 255);">Jordi Palet Martinez.</span></font><div><font color="#007aff"><span style="caret-color: rgb(0, 122, 255);"><br></span></font></div><div><font color="#007aff"><span style="caret-color: rgb(0, 122, 255);">For those unfamiliar with them, MAP-T and 464XLAT are each deployment frameworks for IPv4/IPv6 translation, as described in RFCs 4164, 4166, 4167, and 7915.<br></span></font><br><div dir="ltr">Sent from my iPad</div><div dir="ltr"><br><blockquote type="cite">On Jul 22, 2020, at 2:16 PM, Brian Johnson <brian.johnson@netgeek.us> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Has anyone implemented a MAP-T solution in production? I am looking for feedback on this as a deployment strategy for an IPv6 only core design. My concern is MAP-T CE stability and overhead on the network. The BR will have to do overloaded NAT anyway to access IPv4 only resources. The idea being that when IPv4 is no longer needed, this will be a quicker “clean-up” project than a dual-stack solution.</span><br><span></span><br><span>I have reviewed Jordan Gotlieb’s presentation from Charter and would love to hear if this is still in use at Charter or if was ever fully implemented and the experiences)</span><br><span></span><br><span>I’d love any real life examples and success/failure stories.</span><br><span></span><br><span>Thanks.</span><br><span></span><br><span>- Brian</span></div></blockquote></div></body></html>