Edward, If you find it of use, here's a write-up about fully virtual lab setup with OpenWRT with some screenshots:
http://docwiki.cisco.com/wiki/MAP:OpenWRT_on_kvm_with_MAP-T_example it uses MAP-T, but with the way the MAP/LW4o6 is done in OpenWRT, the difference is very tiny, and this lab is a reasonable starting point for playing. NB: iptables code for partial NAT with counting which was used to avoid reinventing the bicycle, does endpoint-dependent NAT. During the implementation, we made an executive decision guided by KISS principle and called it "a feature" - with the footnote that provisioning the CPE with a 1:1 mapping (i.e. full IPv4 address) configures the regular SNAT, which thus should be endpoint independent. Another implementation you might wanna play with is https://github.com/cernet/MAP - that one is standalone running on Linux, and does implement the entirety of the MAP - though does not have the DHCPv6 provisioning built in. --a On 10/22/15, Edward Lopez <[email protected]> wrote: > Thanks! I’m interested in solutions that have implementations available, > and OpenWRT would do nicely > >> On Oct 22, 2015, at 5:19 PM, Gottlieb, Jordan J >> <[email protected]> wrote: >> >> Edward, >> >> MAP-T (RFC7599) and MAP-E (RFC7577) also address the issues you describe. >> Both CE MAP variants can be enabled in OpenWRT and can be provisioned >> manually or through DHCPv6 (RFC7598). Another excellent manual >> provisioned implementation is at http://enog.jp/~masakazu/vyatta/map/. >> There are several commercial CE and BR implementations in the pipeline >> for MAP-T. >> >> -Jordan >> >> -----Original Message----- >> From: Softwires [mailto:[email protected]] On Behalf Of Edward >> Lopez >> Sent: Wednesday, October 21, 2015 6:29 AM >> To: [email protected] >> Subject: [Softwires] DS-Lite vs. 4rd >> >> I apologize if this has been thrashed out in the past. In looking as >> implementing DS-Lite support, it appears that the need to include an >> additional tuple of information on the IPv6 B4 address of the CPE is >> cumbersome to NAT performance and tunnel capacitance, as many HW >> accelerated NAT engines exist without this extra tuple. It would appear >> that by splitting the AFTR into two functions, 4in6 encapsulation & >> NAT(CGN), we can overcome scaling and performance issues of DS-Lite. >> >> However, the issue of overlapping endpoint subnets supported internally by >> the CPE leads to the issue potentially supporting NAT44 on the CPE, to >> support stateless encapsulation of returning IPv4 packets into IPv6 by the >> AFTR. Section 4.2 of RFC-6333 states that CPE devices ‘should not’ >> perform NAT44, but that’s not the same as a ‘must not’ >> >> But as you craft this solution out, you begin to realize that you are >> re-creating the majority of 4rd, RFC-7600. However, 4rd is currently an >> experimental standard. >> >> My questions: >> >> - Has anyone implemented or considered implementing DS-Lite with CPEs >> performing NAT44? >> - Are their plans for this WG to move 4rd into standards track? >> - Are their any known implementations of 4rd out there for CPE devices >> (like OpenWRT)? >> >> Thanks! >> Ed Lopez >> *** Please note that this message and any attachments may contain >> confidential and proprietary material and information and are intended >> only for the use of the intended recipient(s). If you are not the intended >> recipient, you are hereby notified that any review, use, disclosure, >> dissemination, distribution or copying of this message and any attachments >> is strictly prohibited. If you have received this email in error, please >> immediately notify the sender and destroy this e-mail and any attachments >> and all copies, whether electronic or printed. >> Please also note that any views, opinions, conclusions or commitments >> expressed in this message are those of the individual sender and do not >> necessarily reflect the views of Fortinet, Inc., its affiliates, and >> emails are not binding on Fortinet and only a writing manually signed by >> Fortinet's General Counsel can be a binding commitment of Fortinet to >> Fortinet's customers or partners. Thank you. ** >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > > *** Please note that this message and any attachments may contain > confidential > and proprietary material and information and are intended only for the use > of > the intended recipient(s). If you are not the intended recipient, you are > hereby > notified that any review, use, disclosure, dissemination, distribution or > copying > of this message and any attachments is strictly prohibited. If you have > received > this email in error, please immediately notify the sender and destroy this > e-mail > and any attachments and all copies, whether electronic or printed. > Please also note that any views, opinions, conclusions or commitments > expressed > in this message are those of the individual sender and do not necessarily > reflect > the views of Fortinet, Inc., its affiliates, and emails are not binding on > Fortinet and only a writing manually signed by Fortinet's General Counsel > can be > a binding commitment of Fortinet to Fortinet's customers or partners. Thank > you. *** > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
