George, Wes
2013-01-22 17:12:38 UTC
The draft draft-ietf-6man-addr-select-opt discusses a method to distribute address selection policies via DHCPv6 that potentially override the default RFC6724 policies.
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-08
Since Sunset4 has been discussing the potential need to communicate not just address selection within IPv6, but also potentially between IPv4 and IPv6, it may be worth considering some additional functionality or use cases in this draft or as a companion draft to cover the milestone in the sunset4 charter about signaling end hosts to disable or depreference the use of IPv4. There is also the potential for other, more complex use cases to determine the proper preference for a given destination if and when an ISP is offering some combination of: Native IPv4, IPv4 + CGN, Native IPv6, IPv6 + DNS64/NAT64, etc. We don't necessarily have to make recommendations on what the preferences should be, but it may be useful to illustrate these problems in the draft and provide the framework to communicate more complex preferences based on the individual implementers' situation. It would also be helpful to be clear about the limitations of the complexity these options can realistically and scalably represent - it's unlikely that this can be used for very granular programming of an end host about which method to use for a large subset of distinct prefixes, so an upper bound might be appropriate.
Thanks,
Wes George
________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-08
Since Sunset4 has been discussing the potential need to communicate not just address selection within IPv6, but also potentially between IPv4 and IPv6, it may be worth considering some additional functionality or use cases in this draft or as a companion draft to cover the milestone in the sunset4 charter about signaling end hosts to disable or depreference the use of IPv4. There is also the potential for other, more complex use cases to determine the proper preference for a given destination if and when an ISP is offering some combination of: Native IPv4, IPv4 + CGN, Native IPv6, IPv6 + DNS64/NAT64, etc. We don't necessarily have to make recommendations on what the preferences should be, but it may be useful to illustrate these problems in the draft and provide the framework to communicate more complex preferences based on the individual implementers' situation. It would also be helpful to be clear about the limitations of the complexity these options can realistically and scalably represent - it's unlikely that this can be used for very granular programming of an end host about which method to use for a large subset of distinct prefixes, so an upper bound might be appropriate.
Thanks,
Wes George
________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.