Subject: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-gwinit-6rd-02

From: Tom Taylor <[email-masked]>
Date: Wed, 8 Dec 2010 07:38:44 -0500

We have updated this document to allow for any type of tunnel, not just 
6-in-4. Delegated addresses now mimic the 6rd form, but we supply a 
reasonably credible example of how to derive /56 or even /48 from that form.

-------- Original Message --------
Subject: New Version Notification for draft-tsou-softwire-gwinit-6rd-02
Date: Wed,  8 Dec 2010 00:14:47 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked],[email-masked],[email-masked]

A new version of I-D, draft-tsou-softwire-gwinit-6rd-02.txt has been 
successfully submitted by Cathy Zhou and posted to the IETF repository.

Filename:	 draft-tsou-softwire-gwinit-6rd
Revision:	 02
Title:		 "Gateway-Initiated" 6rd
Creation_date:	 2010-12-08
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document proposes a modification to the 6rd deployment model for
IPv6.  The basic 6rd model allows IPv6 hosts to gain access to IPv6
networks across an IPv4 access network using 6-in-4 tunnels. 6rd
requires support by a device (the 6rd CE) on the customer site, which
must also be assigned an IPv4 address.  The alternative model
described in this document uses tunnels from operator-owned "6rd
Gateways" collocated with the operator's IPv4 network edge.  The
tunnels may be provisioned or automatic.  The advantages of this
approach are that it requires no modification to customer equipment
and avoids assignment of IPv4 addresses to customer equipment.  It
also allows the 6rd prefix portion of the prefixes delegated to
customer devices to be longer than can generally be achieved by basic
6rd.  The gateway initiated 6rd model reuses the protocol defined in
RFC 5969.

The IETF Secretariat.

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Dec 2010 18:26:38 +0100

Le 8 déc. 2010 à 13:38, Tom Taylor a écrit :

May I suggest some amendments to the abstract that, IMHO, better explain what GI 6rd does, and avoids its interpretation as a criticism of the 6rd of RFC 5969? 

If agreed for the abstract, amendments to the draft can be made accordingly (and I could contribute if needed).

1.
Replace "This document proposes a modification to the 6rd deployment model for IPv6."
by "This document proposes a deployment model of 6rd that is additional to the basic model of RFC 5969."
Reason: the deployment model of RFC 5969 still holds, and needs not to be modified.

2.
Before "6rd requires support by a device (the 6rd CE) on the customer site"
add "In RFC 5969,"  

3.
Replace "The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment."
by "Where access networks can directly support native IPv6, the advantage of this approach is that customer equipment only needs to support natively-routed IPv6, as opposed to support also 6rd. Besides, it can apply even across access networks in which IPv4 isn't deployed."
Reasons: 
- This advantage only applies where access networks, in particular their hardware, supports native IPv6.
- A CPE that is IPv4-only also needs to be modified. 
- Providing IPv6 only to customers where IPv4 could be also provided is not always an advantage. This can be a disadvantage where customers are permitted to use their own CPEs.

Regards,
RD

---

From: Tina Tsou <[email-masked]>
Date: Fri, 10 Dec 2010 13:11:56 -0800

Hi Remi,
Agree with the spirit of your proposals. I may rearrange text to provide an
explicit applicability statement for basic 6rd vs. gateway initiated 6rd.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rémi Després
Sent: Friday, December 10, 2010 9:27 AM
To: Tom Taylor
Cc: Softwires
Subject: Re: [Softwires] Fwd: New Version Notification for
draft-tsou-softwire-gwinit-6rd-02

May I suggest some amendments to the abstract that, IMHO, better explain
what GI 6rd does, and avoids its interpretation as a criticism of the 6rd of
RFC 5969? 

If agreed for the abstract, amendments to the draft can be made accordingly
(and I could contribute if needed).

1.
Replace "This document proposes a modification to the 6rd deployment model
for IPv6."
by "This document proposes a deployment model of 6rd that is additional to
the basic model of RFC 5969."
Reason: the deployment model of RFC 5969 still holds, and needs not to be
modified.

2.

3.
Replace "The advantages of this approach are that it requires no
modification to customer equipment and avoids assignment of IPv4 addresses
to customer equipment."
by "Where access networks can directly support native IPv6, the advantage of
this approach is that customer equipment only needs to support
natively-routed IPv6, as opposed to support also 6rd. Besides, it can apply
even across access networks in which IPv4 isn't deployed."
Reasons: 
- This advantage only applies where access networks, in particular their
hardware, supports native IPv6.
- A CPE that is IPv4-only also needs to be modified. 
- Providing IPv6 only to customers where IPv4 could be also provided is not
always an advantage. This can be a disadvantage where customers are
permitted to use their own CPEs.

Regards,
RD

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 21 Dec 2010 02:13:38 +0000

Hi Tom,

In Section 3.1, the 6rd Prefix Delegation consists of p-bit, o-bit, and
m-bit. Can we show us an example how to support a customer who has a v6
CPE at home? Will the 6rd-GW delegate a PD not from the 6rd Prefix to the
home gateway? 

Also, the draft uses o-bit to identify the GW, so the 6rd-BR must have a
table to map the GW-ID to the IPv4 address assigned to the GW. This will
make the BR stateful and break the stateless nature of RFC5969.

Regards,
Yiu

---

From: Tina Tsou <[email-masked]>
Date: Tue, 21 Dec 2010 21:54:16 -0800

Hi Yiu,
Thanks for asking. Answers below.

Happy holidays,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lee, Yiu
Sent: Monday, December 20, 2010 6:14 PM
To: Tom Taylor; Softwires
Subject: Re: [Softwires] Fwd: New Version Notification for
draft-tsou-softwire-gwinit-6rd-02

Hi Tom,

In Section 3.1, the 6rd Prefix Delegation consists of p-bit, o-bit, and
m-bit. Can we show us an example how to support a customer who has a v6
CPE at home? Will the 6rd-GW delegate a PD not from the 6rd Prefix to the
home gateway? 
[Tina: One possibility is that the initial prefix potentially varies 
per customer (e.g., depending on service class) and is available from AAA.
However, the set of possible initial prefixes has to be limited so the 
BR can recognize that it can extract a Gateway Identifier (i.e., tunnel 
identifier, see next response) from a given incoming packet.]

[Tina: If the tunnel is IPv6 in IPv4, the GW identifier is the 
compressed IPv4 address of the GW, as in RFC 5969. For other types of
tunnel, I 
expect (but haven't worked it out in detail) that the identifier would 
be some sort of tunnel identifier. The catch would be to have an 
identifier that is common to both the GW and BR ends and fits in the 
bits available.]

Regards,
Yiu