Re: [Softwires] DS-Lite vs. 4rd

[Andrew 👽 Yourtchenko <[e-mail]>]

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 <[e-mail]> 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
>> <[e-mail]> 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:[e-mail]] On Behalf Of Edward
>> Lopez
>> Sent: Wednesday, October 21, 2015 6:29 AM
>> To: [e-mail]
>> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>