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

Hi Yiu,
Thanks for asking. Answers below.

Happy holidays,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] 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.]

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.

[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

On 12/8/10 7:38 AM, "Tom Taylor" <tom111.taylor@bell.net> wrote:

>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 <idsubmission@ietf.org>
>To: cathyzhou@huawei.com
>CC: tena@huawei.com,tom111.taylor@bell.net,chenqi.0819@gmail.com
>
>
>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.
>
>
>
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires