some part are same as Brian, and we has been tried to write in the Problem statement
- Currently we already have coexistence of VPN access and Global Internet Access in a site
- demands for controlling prefixes exists in some cases - ULA has been reached consensus among IETF - demands for controlling v4-v6 preferenceIf you have further comments of the cases we listed up in it seems to be found wrong, let me know.
On 2007/07/25, at 0:10, Jun-ichiro itojun Hagino wrote:
Thanks for the attention. Before moving to "draft-fujisaki-dhc-addr-select-04.txt", I would like to discuss on what is the best way to this WG with solution draft. Because "draft-fujisaki-dhc-addr-select-04.txt" describes specific protocol to send policy from dhcp server. If all of you think we can skip the discussion about solution (analysis for the solution) and welcome to move to get into protocol work, it is also happy with me. How do you think? Or in parallel with solution draft, if we can discuss on the distribution of site-wide RFC3484 policy it it better. Here we already have "problem statement" and "requirement", the problems wants to be solved, doesn't it?it is a bit of "over the top" comment, but my take on this problem is (as mentioned at the wg meeting) like below: - the entire "source address selection" stuff was a mistake. network has to be deployed so that any ip6_src/ip6_dst pair can go out of the organization somehow.(a) if there's some issue like uRPF in some of your ISPs, the egressrouters in your organization should implement source-based routing to workaround it. (b) the whole idea of ULA/ULA-x should be killed at once. we killed site-locals because to this. do not re-invite rosemary's baby. - alain durand said that he would prefer to have single IPv6 address on a node. i would not go that far (for renumbering and multi- address multihoming) but i object to have addresses with different reachability or "scoping". - so, there's no need for you to think about "distributing source address selection policy". tnx. itojun
------------------------------- Ruri Hiromi hiromi@inetcore.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature