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

From: [email-masked]
Date: Fri, 27 May 2011 16:37:59 -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)       : Alain Durand
                          Ralph Droms
                          James Woodyatt
                          Yiu L. Lee
	Filename        : draft-ietf-softwire-dual-stack-lite-11.txt
	Pages           : 33
	Date            : 2011-05-27

   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-11.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-11.txt

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 28 May 2011 14:42:36 +0200

Hi,

maybe just nitpicking, but...

A.3.  High availability
[...]
   An important element in the design of the Dual-Stack Lite technology
   is the simplicity of implementation on the customer side.  An IP4-in-
   IPv6 tunnel and a default route over it in the B4 element are all is
   needed to get IPv4 connectivity.  It is assumed that high
   availability is the responsibility of the service provider, not the
   customer devices implementing Dual-Stack Lite.  As such, a single
   IPv6 address of the tunnel end-point is provided in the DHCPv6 option
   defined in [I-D.ietf-softwire-ds-lite-tunnel-option].
[...]

This ain't strictly correct.

Unfortunately[1], the DHCPv6 option was changed to provide an FQDN which
then has to be resolved to AAAAs by the B4 chosing one of them in an
unspecified way.

Best regards,
Daniel

[1] now you need working IPv6 DNS resolution to get IPv4 connectivity up
and running (ARGH!), adding unnecessary complexity in B4 initialization
and nondeterministic B4 behaviour in regard of AAAA choice, making any
load balancing mechanism based on returning multiple AAAA infeasible due
to possible biassing. While load balancing could have been achieved via
plain IPv6 address DHCPv6 option just fine, leaving it up to the DHCPv6
server issuing AFTR addresses in a balanced fashion.

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Sat, 28 May 2011 19:20:07 +0000

Hi Daniel,

Actually, there was a long discussion in the mailing list to argue to use
FQDN or AAAA address. I personally support to use only AAAA record in the
dhcpv6 option, but some operators prefer to use FQDN for more flexibility.
As you pointed out, this flexibility does come with cost. We leave the
AAAA selection process undefined because each ISP may have slightly
different requirement for LB. However, this also causes undefined behavior
for off-the-shelf home gateway with ds-lite. If an ISP decided to use
plain IPv6 address, it must make sure each FQDN only returns one AAAA
record.

B.R.,
Yiu