Subject: Re: [v6ops] 6rd Sunsetting

From: "Frank Bulk" <[email-masked]>
Date: Sat, 3 Dec 2011 21:07:49 -0600

Hemant:

If this CPE has manually-configured 6rd configured, why would the CPE sunset
6rd at all?  Since Barbara perceives manually-configured CPE primarily in
PPP environments, how would DHCPv4 play into this situation at all?  

I'd like to hear from Barbara how she would want a CPE with
manually-configured 6rd should function in the presence of native IPv6, both
in DHCPv6 and PPP environments.

Frank

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Monday, November 28, 2011 1:25 PM
To: Mark Townsley; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

From: Mark Townsley [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>OK, I won't stand in the way of including manual requirements under
protest, but if they go in then it becomes that much more important that the
CE be able to rationalize 6rd and native at the same time. I >don't think it
changes the requirements at all if we follow the same general principle that
the CE "does what it is told" rather than trying to enable and disable 6rd
configuration dynamically based on the >presence of native IPv6. 

The retail, manually-configured CPE will be fine with 6rd sunsetting based
on the rules already specified in rfc6204bis.  The rules are agnostic to a
SP-managed or a user-configured 6rd CPE router. The retail CPE will start
native IPv6 operation when cued to do so with a RA from the SP BNG and
sunset 6rd when the DHCPv4 lease_time expires and the SP does not reply to
the DHCPv4 Renew from the CPE and the SP has also changing the provisioning
system to not include the 6rd DHCPv4 option in DHCPv4 responses.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 4 Dec 2011 08:32:28 -0600

Frank,

From: Frank Bulk [mailto:[email-masked]] 
Sent: Saturday, December 03, 2011 10:08 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; Mark Townsley; STARK, BARBARA H
Subject: RE: [v6ops] 6rd Sunsetting

>If this CPE has manually-configured 6rd configured, why would the CPE
sunset 6rd at all?  Since Barbara perceives manually->configured CPE
primarily in PPP environments, how would DHCPv4 play into this situation
at all?  

If there is no DHCPv4 in the network, you are correct.   However,
consider this.  The CPE is running 6rd.  Then CPE receives an RA,
initiates DHCPv6 PD, and gets operational in native IPv6 mode.   Since
the SP issued the RA the SP has also disabled 6rd.  Now the CPE has to
send data on the 6rd tunnel.  The CPE issues a RFC 5969 NUD to the BR.
The NUD is not responded to since the SP has disabled 6rd.  On the NUD
timing out the CPE disables 6rd and just keeps protocol 41 processing
active.

Having said that, I still prefer symmetry.  If DHCPv4 was used to enable
6rd, DHCPv4 should be used to disable 6rd.  Likewise if manual
configuration was used to enable 6rd, manual configuration should also
be used to disabled 6rd.   Note also, MarkT has said, 6rd in RFC 5969
was designed for SP-managed CPE and manually configured CPE is out of
scope for RFC 5969.  Likewise any manual configuration is out of scope
of rfc6204bis as well.   

>I'd like to hear from Barbara how she would want a CPE with
manually-configured 6rd should function in the presence of >native IPv6,
both in DHCPv6 and PPP environments.

Barbara can reply to this one.

Regards,

Hemant

---

From: Tina TSOU <[email-masked]>
Date: Mon, 05 Dec 2011 17:55:13 +0000

Please see comments inline.

Thanks,
Tina
From: "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>>
Date: December 4, 2011 6:32:28 AM PST
To: Frank Bulk <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] 6rd Sunsetting
Frank,

Cc: [email-masked]<mailto:[email-masked]>; Mark Townsley; STARK, BARBARA H

>If this CPE has manually-configured 6rd configured, why would the CPE sunset 6rd at all?  Since Barbara perceives manually->configured CPE primarily in PPP environments, how would DHCPv4 play into this situation at all?

If there is no DHCPv4 in the network, you are correct.   However, consider this.  The CPE is running 6rd.  Then CPE receives an RA, initiates DHCPv6 PD, and gets operational in native IPv6 mode.   Since the SP issued the RA the SP has also disabled 6rd.  Now the CPE has to send data on the 6rd tunnel.  The CPE issues a RFC 5969 NUD to the BR.  The NUD is not responded to since the SP has disabled 6rd.  On the NUD timing out the CPE disables 6rd and just keeps protocol 41 processing active.
 >>>>>>>>>>>>>>>>>>>I have a doubt here....
>>>>>>>>>>>>>>>>>>>>>if native link is active and since we have given higher priority to using the native interface....the CPE will send data through 6rd tunnel only if native is inactive or it cannot reach a destination over the native path. So one possibility I think if I have to disable 6rd manually ,I can simply remove the route for 6rd from the FIB.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Having said that, I still prefer symmetry.  If DHCPv4 was used to enable 6rd, DHCPv4 should be used to disable 6rd.  Likewise if manual configuration was used to enable 6rd, manual configuration should also be used to disabled 6rd.   Note also, MarkT has said, 6rd in RFC 5969 was designed for SP-managed CPE and manually configured CPE is out of scope for RFC 5969.  Likewise any manual configuration is out of scope of rfc6204bis as well.

>I'd like to hear from Barbara how she would want a CPE with manually-configured 6rd should function in the presence of >native IPv6, both in DHCPv6 and PPP environments.

Regards,

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 Dec 2011 13:55:49 -0500

I would expect a manually-configured CE router to behave as we've
discussed:

If the prefix received in a IA_PD is different than the one derived from
6rd (6rd configuration + WAN IPv4 address), then the CE router should
immediately tell the LAN that the 6rd prefix is not preferred, and not
valid (of course there will be the 2 hour window when this is expressed
in RA to the LAN).

If the prefix received in IA_PD is the same, then we will rely on this
"administrative distance" thing to keep traffic away from the 6rd BR. 

I don't think it's a good idea to make the 6rd BR immediately
unavailable after sending RAs. Flash cuts are to be avoided, especially
flash cuts that assume, for example, 100k CE routers transitioning at
the same time. Which means that manual, DHCPv4, and TR-069 configured
6rd implementations should all be prepared to gracefully handle having
both. I don't see why transition from manual is so vastly different, at
the point where a device determines it has both 6rd and native
interfaces. Where it differs, is in the ease of *removing* 6rd
configuration from the device. Even with TR-069, we'd probably want a
soak period before disabling 6rd. So manual configuration soaks a little
(or a lot) longer than the others. 

And to respond to the suggestion that retail CE routers support TR-069:
with my consumer hat on, I say no way, no how - it's *my* router, and no
service provider is going to be allowed to so intrusively manage *my*
router. With my service provider hat on, I say no way - we don't do it
today, and adding such support just for 6rd is out of the question - too
costly, every way you look at it. Again, the goal is to keep it
reasonably simple for service providers, vendors, and the tech-savvy
people who can't stand the idea of service-provider-managed CE routers
in their home network. <personal disclosure: I do not have a service
provider managed CE router in my home; I know what they're capable of,
and don't want such a thing on my home network; fortunately, my service
provider is fine with this, so long as I accept responsibility for my
router's operation; I also never use ISP-provided (or CE router vendor
provided) setup CDs, which load applications that I personally don't
trust onto PCs, instead preferring to *manually configure* my browser,
email client, Wi-Fi, etc.; I believe that all people who are willing to
go to this trouble should be afforded this freedom; for those who are
not, I will work on standards and applications that allow service
providers to do everything for their customers >

Barbara

To: 'Hemant Singh (shemant)'

Hemant:

If this CPE has manually-configured 6rd configured, why would the CPE
sunset 6rd at all?  Since Barbara perceives manually-configured CPE
primarily in PPP environments, how would DHCPv4 play into this situation
at all?  

I'd like to hear from Barbara how she would want a CPE with
manually-configured 6rd should function in the presence of native IPv6,
both in DHCPv6 and PPP environments.

Frank

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Monday, November 28, 2011 1:25 PM
To: Mark Townsley; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>OK, I won't stand in the way of including manual requirements under
protest, but if they go in then it becomes that much more important that
the CE be able to rationalize 6rd and native at the same time. I >don't
think it changes the requirements at all if we follow the same general
principle that the CE "does what it is told" rather than trying to
enable and disable 6rd configuration dynamically based on the >presence
of native IPv6. 

The retail, manually-configured CPE will be fine with 6rd sunsetting
based on the rules already specified in rfc6204bis.  The rules are
agnostic to a SP-managed or a user-configured 6rd CPE router. The retail
CPE will start native IPv6 operation when cued to do so with a RA from
the SP BNG and sunset 6rd when the DHCPv4 lease_time expires and the SP
does not reply to the DHCPv4 Renew from the CPE and the SP has also
changing the provisioning system to not include the 6rd DHCPv4 option in
DHCPv4 responses.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 5 Dec 2011 13:20:25 -0600

Barbara,

Thanks for the reply.  Please see below.

From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Monday, December 05, 2011 1:56 PM
To: Frank Bulk; Hemant Singh (shemant)
Cc: [email-masked]; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

unavailable after sending RAs. Flash cuts are to be avoided, especially
flash cuts >that assume, for example, 100k CE routers transitioning at
the same time. Which means that manual, DHCPv4, and TR-069 configured
6rd >implementations should all be prepared to gracefully handle having
both. I don't see why transition from manual is so vastly different, at
the >point where a device determines it has both 6rd and native
interfaces. Where it differs, is in the ease of *removing* 6rd
configuration from the >device. Even with TR-069, we'd probably want a
soak period before disabling 6rd. So manual configuration soaks a little
(or a lot) longer than the >others. 

I, MarkT and you are in agreement with what you say above.  However,
please see this email during an exchange with Victor on his screw case
with 6rd sunsetting.

http://www.ietf.org/mail-archive/web/v6ops/current/msg11436.html

See the text below from the email URL above between squared braces.

[> 

> Again, I would prefer a cut over from one interface to the other 

> (virtual to native).  This is what I would ask my vendor to implement.

> Once I add in Native to a capable CPE, I would expect the CPE to go 

> native. I am hoping there is an option for this within all the
proposals.

I don't want to limit the ability for you to move a customer from 6rd to
native immediately, but I want others to be able to do it incrementally
as well. If you want to move them immediately, all you need to do is
provision DHCPv6 PD at the same time you deprovision the 6rd option in
DHCPv4 and be sure you use a different prefix for native than 6rd. Once
the home router reboots or the DHCPv4 lease and associated 6rd delegated
prefix lifetime times out, the 6rd and its associated prefix will be
gone never to return. 

- Mark]

>service provider is going to be allowed to so intrusively manage *my*
router. 

So please provide guidance on how is 6rd disabled on the retail router
if 6rd was enabled manually on the retail router?   For a manually
configured retail router, one can run into concurrent DS-Lite and 6rd
operation and then the CE router is totally confused why the router
should not run in native dual-stack mode.    

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 Dec 2011 15:41:59 -0500

I interpreted "stop doing 6rd" as being similar in function to "not
sending any traffic over the 6rd interface". From the outside, it looks
the same. I tend to be more concerned with externally discernible
behavior, than with internal implementation. If (in the case of
different prefixes) the CE router immediately makes IPv6 addresses on
the LAN from the 6rd prefix to be not preferred and not valid, then this
accomplishes that goal. If (for same prefix) the CE router prefers to
send traffic over the native interface, then this also accomplishes the
goal.

Again, I have to point out that in all 3 cases (DHCPv4, TR-069, and
manual configuration) there is a period of time where both are available
to the CE router, unless you try some sort of flash cut. The CE router
must be able to deal with this. And the preference is that it deal with
this by getting as much traffic as possible to go over the native
interface, as soon as possible.

If no traffic is going over the 6rd interface, and the CE router is able
to function with both configured, what is it going to hurt, however long
the manual configuration stays? And the way to disable it is for the
very same user who manually configured it, to go in and manually disable
it. As long as things don't break, it shouldn't really matter. Of
course, I would prefer for the user to disable it sooner rather than
later. But we've dealt with similar transitions before (IP to PPPoE,
PPPoE to IP, PPPoA to PPPoE, TDMA to GSM, IPv4 to IPv6, etc.). It's
do-able. Some users hang on for a long time. Most respond quickly. It's
manageable, as long as things don't break when faced with both.

As for concurrent 6rd and DS-Lite, I really don't care what rules are
created. The situation is only relevant to providers who actually intend
to offer both to the same CE routers. If a provider doesn't offer
DS-Lite DHCPv6 options, then the danger of dealing with CE routers that
have trouble deciding what to do is pretty low.

Barbara

From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Monday, December 05, 2011 2:20 PM
To: STARK, BARBARA H; Frank Bulk
Cc: [email-masked]; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

Barbara,

 

[> 

proposals.

- Mark]

router. 

Hemant

---

From: "Frank Bulk" <[email-masked]>
Date: Wed, 7 Dec 2011 22:19:39 -0600

Sounds like we're hashing out the 6rd sunsetting concerns related to manual
configuration.  

I'm not really keen about focusing on externally discernible behavior - in
this case I think we need to specify what the router should do, making sure
we've done our homework by considering the many possible state transitions
that involve DHCPv4 and 6rd.  If we can't figure out an approach that works
across all possible state transitions, then we should probably define a
subset of situations that lead to the desired behavior.

Frank

From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Monday, December 05, 2011 2:42 PM
To: Hemant Singh (shemant); Frank Bulk
Cc: [email-masked]; Mark Townsley
Subject: RE: [v6ops] 6rd Sunsetting

I interpreted "stop doing 6rd" as being similar in function to "not sending
any traffic over the 6rd interface". From the outside, it looks the same. I
tend to be more concerned with externally discernible behavior, than with
internal implementation. If (in the case of different prefixes) the CE
router immediately makes IPv6 addresses on the LAN from the 6rd prefix to be
not preferred and not valid, then this accomplishes that goal. If (for same
prefix) the CE router prefers to send traffic over the native interface,
then this also accomplishes the goal.

Again, I have to point out that in all 3 cases (DHCPv4, TR-069, and manual
configuration) there is a period of time where both are available to the CE
router, unless you try some sort of flash cut. The CE router must be able to
deal with this. And the preference is that it deal with this by getting as
much traffic as possible to go over the native interface, as soon as
possible.

If no traffic is going over the 6rd interface, and the CE router is able to
function with both configured, what is it going to hurt, however long the
manual configuration stays? And the way to disable it is for the very same
user who manually configured it, to go in and manually disable it. As long
as things don't break, it shouldn't really matter. Of course, I would prefer
for the user to disable it sooner rather than later. But we've dealt with
similar transitions before (IP to PPPoE, PPPoE to IP, PPPoA to PPPoE, TDMA
to GSM, IPv4 to IPv6, etc.). It's do-able. Some users hang on for a long
time. Most respond quickly. It's manageable, as long as things don't break
when faced with both.

As for concurrent 6rd and DS-Lite, I really don't care what rules are
created. The situation is only relevant to providers who actually intend to
offer both to the same CE routers. If a provider doesn't offer DS-Lite
DHCPv6 options, then the danger of dealing with CE routers that have trouble
deciding what to do is pretty low.

Barbara

Barbara,

 

>I don't think it's a good idea to make the 6rd BR immediately unavailable
after sending RAs. Flash cuts are to be avoided, especially flash cuts >that
assume, for example, 100k CE routers transitioning at the same time. Which
means that manual, DHCPv4, and TR-069 configured 6rd >implementations should
all be prepared to gracefully handle having both. I don't see why transition
from manual is so vastly different, at the >point where a device determines
it has both 6rd and native interfaces. Where it differs, is in the ease of
*removing* 6rd configuration from the >device. Even with TR-069, we'd
probably want a soak period before disabling 6rd. So manual configuration
soaks a little (or a lot) longer than the >others. 

I, MarkT and you are in agreement with what you say above.  However, please
see this email during an exchange with Victor on his screw case with 6rd
sunsetting.

[> 

> native. I am hoping there is an option for this within all the proposals.

I don't want to limit the ability for you to move a customer from 6rd to
native immediately, but I want others to be able to do it incrementally as
well. If you want to move them immediately, all you need to do is provision
DHCPv6 PD at the same time you deprovision the 6rd option in DHCPv4 and be
sure you use a different prefix for native than 6rd. Once the home router
reboots or the DHCPv4 lease and associated 6rd delegated prefix lifetime
times out, the 6rd and its associated prefix will be gone never to return. 

- Mark]

router. 

So please provide guidance on how is 6rd disabled on the retail router if
6rd was enabled manually on the retail router?   For a manually configured
retail router, one can run into concurrent DS-Lite and 6rd operation and
then the CE router is totally confused why the router should not run in
native dual-stack mode.    

Hemant