Subject: [Softwires] I-D Action:draft-ietf-softwire-dual-stack-lite-08.txt

From: [email-masked]
Date: Mon, 02 May 2011 10:30:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
	Author(s)       : A. Durand, et al.
	Filename        : draft-ietf-softwire-dual-stack-lite-08.txt
	Pages           : 33
	Date            : 2011-05-02

This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6 in service provider networks.  Dual-stack lite
enables a broadband service provider to share IPv4 addresses among
customers by combining two well-known technologies: IP in IP (IPv4-
in-IPv6) and Network Address Translation (NAT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 3 May 2011 22:15:13 +0200

> 	Filename        : draft-ietf-softwire-dual-stack-lite-08.txt

7.2.  VPN

   Dual-stack lite implementations MUST NOT interfere with the
   functioning of IPv4 or IPv6 VPNs.

This "MUST NOT" was "SHOULD NOT" in -07. What's the motivation for that
change?

Is there a specific problem/scenario which is supposed to be solved? How
is a DS-Lite implementation supposed to not interfere e.g. with
IPSEC-AH (and other VPN types having inherent problems with NAPT44)?

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 3 May 2011 22:15:31 +0000

Hi Daniel,

This change is to address a comment from IESG. Our goal here is to ensure
dslite which is a NAPT44 solution should work like what NAPT44 is supposed
to do today. The word "interfere" should be interpreted that dslite must
not change any existing VPN solutions for NAPT44. It doesn't mean dslite
MUST NOT modify the packet. For example: what defined in RFC3947 and
RFC3948 must not be interfered by dslite.

Best regards,
Yiu

On 5/3/11 4:15 PM, "Daniel Roesen" <[email-masked]> wrote:

>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 4 May 2011 00:35:50 +0200

Hi Yiu,

> RFC3948 must not be interfered by dslite.

Thanks. Shouldn't 7.2 then go under chapter 8 "NAT considerations"?
Aren't VPNs traversing the DS-Lite NAPT44 function covered via 8.2
anyway, implicitly?

DS-Lite specific properties and working except the NAPT44 function are
clearly defined, so where's the room for implementors to infer with
VPNs? Unless I'm missing something, 7.2 is quite redundant to 8.2

BTW, are we talking about CPE-terminated IPv4 VPN tunnels, or IPv4 VPN
tunnels traversing a B4 CPE (read: host behind B4 CPE trying to
establish a VPN tunnel to some VPN hub "out there")?

Best regards,
Daniel

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 5 May 2011 14:25:34 +0000

Hi Daniel,

There are two parts of considerations in dslite, the tunnel part and the
NAPT part. Section 7.2 is on the tunnel consideration. The network must
not interference the VPN packets. Section 8.2 is on the NAPT in the AFTR.
AFTR must support all the requirements in rfc4787 and rfc5382.

We are talking about the host behind B4 element trying to establish a VPN
tunnel.   

Regards,
Yiu