<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#44546A;}
span.currenthithighlight
        {mso-style-name:currenthithighlight;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#44546A'>In my CGNat environment (~11,000 subs (5,000 dsl & 6,000 cable modem)) I had to solve issues with site-to-site vpn, console gaming and some webmail and banking web sites that seem to hand off authentication to another site and try to carry over the ip address … also had to try to accomplish load sharing amongst (3) cgnat nodes on my vrf-to-vrf boundary where I do natting…  here’s some things we did…<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>APP - consistent mapping for priv to pub ip's<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>EIM – stabilizes ports outbound<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>EIF - stabilizes ports inbound and allows for some hold-over (actual pinhole openings) for further comms from outside---to---->inside<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>AMS LB - ams load balancing to occur on src-ip for removing the chance for more ip change*<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>AMS Member Failure options - more of adding resilience if/when underlying npu's fail<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>IGP (OSPF/LDP) routing - not cgnat related at all, and i recall more for load sharing amongst my mx960....but was a big win for us when we found the (set protocols ldp track-igp-metric) trick or causing my PE's that would then use the real igp metric to route to the *igp closest* cgnat node (mx960/ms-mpc-128g) thus causing that cgnat node to always be used for that pe's set of priv ip subs... you must know that i had a triple cgnat node boundary ((3) mx960's w/ms-mpc's) and here again had an issue with all traffic going to the lowest bgp loopback ip tiebreaker since apparently inet.3 has metric 1 for every prefix... that trick ldp command copies inet.0 metric into inet.3 thus giving some real igp metric consideration to the bgp best path calculation<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>* pub ip pool is divided up over the number for npu/vpic's that are aggregated together in an ams... so there is a chance that your priv ip's will be hashed over any and all npu's thus causing greater change of pub ip differences<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>Btw, there are keepalives for eif and sessions limits for resource issues to be considered<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#44546A'>- Aaron<o:p></o:p></span></p><p class=MsoNormal><span style='color:#44546A'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> NANOG [mailto:nanog-bounces@nanog.org] <b>On Behalf Of </b>Philip Loenneker<br><b>Sent:</b> Thursday, October 11, 2018 10:58 PM<br><b>To:</b> NANOG<br><b>Subject:</b> RE: new(ish) ipv6 transition tech status on CPE<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-AU>Hi Tom,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>CGNAT is the most supported by the technology available in pretty much every device. Even keeping an audit trail of IP/port mappings is relatively easy (look into deterministic NAT – it will save you a lot of headache). You can likely lab it up with gear you already have, unlike the newer transition technologies that we’ve been discussing.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>However, from my experience, the customer impact of going through 2 layers of NAT (NAT44) causes a lot of unhappy customers. I enabled it on my home connection for a few weeks to see how it went, and I was surprised that a lot of things just worked… Youtube, Netflix, etc had no issues. But there were key things such as Facebook Messenger voice and video calls that broke, which caused my family to get rather upset with me. Console gaming is also a common area of problems. For these types of Internet services, the profit margin can get eaten up quickly by the helpdesk calls.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>As a side note, from internal discussions here (ie speculation, no real evidence to back it up), home users are likely to be impacted far more than business users, due to the difference in usage. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:JA'>Regar</span><span lang=EN-AU>ds,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU>Philip</span><u><span lang=EN-AU style='font-size:10.0pt;color:#ED7D31'><o:p></o:p></span></u></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><b>From:</b> NANOG <nanog-bounces@nanog.org> <b>On Behalf Of </b>Tom Ammon<br><b>Sent:</b> Friday, 12 October 2018 2:39 PM<br><b>To:</b> NANOG <nanog@nanog.org><br><b>Subject:</b> Re: new(ish) ipv6 transition tech status on CPE<o:p></o:p></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-AU><o:p> </o:p></span></p><div><div><p class=MsoNormal><span lang=EN-AU>On Wed, Oct 10, 2018 at 3:08 PM Brock Tice <<a href="mailto:brock@bmwl.co">brock@bmwl.co</a>> wrote:<o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-AU>On 10/09/2018 06:24 PM, Philip Loenneker wrote:<br>> I have asked several vendors we deal with about the newer technologies<br>> such as 464XLAT, and have had some responses indicating they will<br>> investigate internally, however we have not made much progress yet. One<br>> vendor suggested their device supports NAT46 and NAT64 so may support<br>> 464XLAT, but since it is incidental rather than an official feature, it<br>> may not support the full CLAT requirements. I have been meaning to do<br>> some tests but haven’t had a chance yet. It is also a higher price point<br>> than our current CPEs.<br>> <br>>  <br>> <br>> I have spoken to people who have looked into options such as OpenWRT<br>> (which supports several of these technolgoies), however the R&D and<br>> ongoing support is a significant roadblock to overcome.<br>> <br><br>We looked into this somewhat intently ~6 months ago and had not much<br>luck from vendors. Barely on their radar if at all.<br><br>We used our own custom OpenWRT build on a few select, tested consumer<br>routers to do 464XLAT. In the end we went to dual-stack with CGN on<br>IPv4. I wrote up some documentation on how we did it on my blog, but in<br>the end I can't recommend the setup we used.<br><br>I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I<br>would be ready to give it another shot.<o:p></o:p></span></p></blockquote></div><p class=MsoNormal><span lang=EN-AU><br clear=all><o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-AU>It sounds like I am where you were 6 months ago. We've been looking at NAT64, MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4 side. What did you experience with the dual-stack/CGN approach that keeps you from recommending it? Academically, that setup seems the least fraught with problems among all of the options.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p></div><p class=MsoNormal><span lang=EN-AU>-- <o:p></o:p></span></p><div><div><div><div><p class=MsoNormal><span lang=EN-AU>-----------------------------------------------------------------------------<br>Tom Ammon<br>M: (801) 784-2628<br><a href="mailto:thomasammon@gmail.com" target="_blank">thomasammon@gmail.com</a><br>-----------------------------------------------------------------------------<o:p></o:p></span></p></div></div></div></div></div></div></body></html>