Re: [v6ops] new draft: draft-yang-v6ops-ipv6tran-select

["STARK, BARBARA H" <[e-mail]>]

Since no-one else has replied to this, I'll provide my thoughts.
My personal opinion is that I do not consider the proposed DHCP options to be particularly useful.

My primary concern:
The draft states that these options are being proposed for the purpose of IPv6 transition trials and experiments. As such, I would be opposed to recommending that CE router manufacturers implement the options -- I do not believe that all manufacturers of retail or operator-provided CE routers worldwide should feel in any way obliged to provide experimental and trial capabilities. And if these options are not recommended and implemented, then they serve no use. If the only routers implementing the options are from vendors being influenced by providers doing these trials, then the same effect could be had by the provider (or even a group of providers) publishing vendor-specific DHCPv4 and DHCPv6 options. Also note that there is not a long-term need to support capabilities enabling trials and experiments of IPv6 transition technologies -- at least, I sure hope it's not a long-term need.

My secondary comments:
The authors do not explain why existing 6rd DHCPv4 configuration option, DS-Lite DHCPv6 options, and DHCPv4 IPv4 address offers + DHCPv6 IA_PD/IA_NA are insufficient for configuration of 6rd, DS-Lite, and "dual stack". It is true that many retail CE routers disable these functions in their factory default configurations. However, it is quite possible to develop code in such a way that the capabilities are automatically enabled when their existing configuration options are received. Since code that requires manual enabling/disabling is much simpler, I support manufacturers' freedom to choose the simpler route when coding these functions. But in provider-procured CE routers, it should be very possible for the provider to specify the desired behavior.

The authors suggest that remote management of CE routers (especially when multiple vendors are involved) is problematic. However, I believe that many providers have successfully used TR-069 or SNMP to manage the IPv6 capabilities of devices they provide (which may be from a variety of vendors). These are standard management protocols that are widely implemented, and there exist standard IPv6 TR-069 data models and SNMP MIBs for managing these capabilities. I believe that a number of providers worldwide have done trails and deployments of these IPv6 technologies, and have been able to successfully manage these capabilities in the CE routers that they have provided. 

I am aware that many providers choose not to manage CE routers that they provide, or do not even provide CE routers (so customers must purchase a retail CE router, if they want a CE router). But since this is not a practice or problem shared by all operators, and is a choice that each operator is free to make, I would again say that I am opposed to requiring all operators' CE routers to have these DHCP options, and I am opposed to recommending that vendors of retail CE routers should feel obliged to implement a new option just so their equipment can be used in such trials. I am aware of several providers who have customers who do not have the option of operator-provided CE routers, who are successfully conducting trials or deployments of 6rd. Personally, I subscribe to broadband connections from 2 different providers, neither of whom provides me with the option of getting a CE router from them. Both have published their 6rd connectivity information and freely allow any of their customers to participate in these trials. I have chosen to participate in both of these trials. When I received an email from one of my providers that I could do IPv6 using 6rd, I went to my local electronics superstore, bought the cheapest IPv6/6rd-capable router (as noted on the packaging) that I could find, and tried it out. It was incredibly easy. But given that I had to purposefully make the trip to the store and carefully read the packaging, I think it's pretty clear that such trials are targeted at people like me, and not at "average" consumers. It was also interesting to note that most of the CE routers on the store shelves were not 6rd-capable.  If an "average" consumer happens (by pure coincidence) to purchase a 6rd-capable router, I don't think it's a very good idea to try to automate that customer's 6rd trial participation. If an operator is so unsure of or uncommitted to a technology that they are not willing to fully deploy it, then causing unsuspecting customers to participate in a trial may not be the best idea. Because I knew that I was enabling IPv6, I could have easily disabled it, if my Internet connectivity experience had been negatively impacted. Unsuspecting, automatically-participating, "average" customers would not be so fortunate.

I recognize that there are regional variations in operator behavior. But, again, I would like to suggest that it is possible for operators in a particular region to publish their own vendor-specific DHCP options, and influence manufacturers doing business in that region to implement them. Or they can publish the information (as both of my providers have done) and allow for purely voluntary participation by "technologically savvy" customers. There is no need for a world-wide standardized DHCP option for conducting trials and experiments of IPv6 transition technologies.
Barbara

> -----Original Message-----
> We find some inconvenient issues about CPE when we do IPv6 trials and
> experiments:
>          1、ISP must pre-configure IPv6 transition technology in CPE, such as
> dual-stack, DS-Lite, and so on.
>          2、Otherwise, ISP must rely on Manage System to control CPEs. But if
> CPEs are form different manufactories, they need different Manage System,
> or to develop consistent interface in the Manage System.
>          3、If users change the CPE ISP giving to them to another one with
> incorrect configuration, or configure CPE incorrectly by mistake, they cannot
> access internet.
> In this document, we propose a solution to solve the problem. But, the most
> important issue is to propose this problem, not the solution.
> 
> Wish for your comments. Thank you!
> 
> Tianle Yang
> 
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select. Please take a
> look at it and comment.