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

From: Edward Lopez <[email-masked]>
Date: Wed, 21 Oct 2015 12:29:26 +0000

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. **

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 22 Oct 2015 02:50:51 +0000

Hi Edward,

> -	Has anyone implemented or considered implementing DS-Lite with CPEs performing NAT44?

Have you looked at RFC7596 (Lightweight 4over6)? Its main goal was to move 
the NAT to the B4 (CPE) from the AFTR.

Thanks
Suresh

---

From: "Gottlieb, Jordan J" <[email-masked]>
Date: Thu, 22 Oct 2015 16:19:37 -0500

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-masked]] On Behalf Of Edward Lopez
Sent: Wednesday, October 21, 2015 6:29 AM
To: [email-masked]
Subject: [Softwires] DS-Lite vs. 4rd

My questions:

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-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Edward Lopez <[email-masked]>
Date: Thu, 22 Oct 2015 21:49:31 +0000

Thank you, I will review this.

On Oct 21, 2015, at 10:50 PM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:

Hi Edward,

My questions:

Thanks
Suresh

a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Edward Lopez <[email-masked]>
Date: Thu, 22 Oct 2015 21:50:35 +0000

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-masked]> wrote:
> 
> Edward,
>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 23 Oct 2015 09:13:49 +0000

Dear Edward,

Qiong could send you the LW4o6 OpenWRT link.

Thank you,
Tina

> 在 2015年10月23日，上午5:50，Edward Lopez <[email-masked]> 写道：
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 23 Oct 2015 15:59:39 +0200

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-masked]> wrote:
>> 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
>>
>> 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:
>>
>> ***  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. **