Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

François-Xavier,

Another person told us that the Coexistence section could be clarified more.  We did have implicit assumptions that Wes Beebee expanded to this text below in an internal discussion. Wes' text is shown between squared braces below.

[Process #1, #2, #3, and #4 are spawned simultaneously.  Process #3 blocks immediately until process #1 provides a useable IPv4 address, along with all of the information necessary to allow 6rd configuration to proceed.  Process #4 blocks immediately until process #2 provides a useable IPv6 address, along with all of the information necessary to allow DS-Lite configuration to proceed.  At the end of configuration, if all four processes succeed in provisioning, then routing determines which of the four are actually used for sending traffic.  If and only if #1 is available, then #4 is not used and #1 is used while available.  If and only if #2 is available, then #3 is not used and #2 is used while available.]

Seeing the above text,  we clarified the rules.  See new text below that we want to replace the current Coexistence section with. 

---------- new text ---------
1.    Initiate native IPv4/IPv6 provisioning (e.g via DHCP) simultaneously. 
2.    After IPv4 provisioning completes, if 6rd parameters are included in the DHCPv4 reply or configured on the device, initiate 6rd. 
3.    After IPv6 provisioning completes, if DS-Lite parameters are included in the DHCPv6 reply or configured on the device, initiate DS-Lite. 
4.    Routes over the DS-Lite tunnel always have a higher administrative distance than native v4 routes. 
5.    Routes over the 6rd tunnel always have a higher administrative distance than native v6 routes. 
6.    If DS-Lite and 6rd are both configured, do not route 6rd over a DS-Lite tunnel or DS-Lite over a 6rd tunnel.

During a sunsetting activity such as deprecating 6rd and moving to native IPv6, due to the two hours rule specified in RFC 4862, the 6rd and the native IPv6 prefix will coexist in the home network.  The two hours rule specified in section 5.5.3 of RFC 4862 causes any deprecated prefix to linger on the node even when an RA has sent a Valid Lifetime of zero to expire the prefix to the node.  During such coexistence of multiple prefixes, the CE router sends an ICMPv6 error for packets sourced or destined related to the deprecated prefix.  Note RFC 6204 already includes text in bullet L-14 in section 4.3 for such a provision.

------- end new text ---------

Thanks,

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of François-Xavier Le Bail
Sent: Thursday, October 13, 2011 10:47 AM
To: v6ops@ietf.org
Cc: draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hi,

RFC 6333 states:
"Tunneling MUST be done in accordance to [RFC2473] and [RFC4213]."

RFC 2473 states that there is a need for an IPv6 Tunnel Entry-Point Node 
Address (and an IPv6 Tunnel Exit-Point Node Address) to build the tunnel 
IPv6 header.

So, in draft-ietf-v6ops-6204bis §4.4.3. Transition Technologies 
Coexistence, I think that the stage 4 requires the ending of the stage 2.
Is it the parallelism of the stages 2 and 4 possible?

Cheers,
François-Xavier Le Bail

--- On Tue, 10/11/11, fred@cisco.com <fred@cisco.com> wrote:

> From: fred@cisco.com <fred@cisco.com>
> Subject: [v6ops] new draft: draft-ietf-v6ops-6204bis
> To: v6ops@ietf.org
> Cc: draft-ietf-v6ops-6204bis@tools.ietf.org
> Date: Tuesday, October 11, 2011, 9:55 AM
> 
> A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-6204bis.
> Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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