Dan, thank you for your comments. My responses below.
>> >> Hi, >> >> let me summarize the discussion we had about address selection, >> and move on to the next-step. >> >> The discussion was about a try-and-error based mechanism proposed >> by Fred Baker, and the address selection design team's proposal, >> which is based on policy distribution. >> >> >> * Fred's proposal. >> - A host tries each pair of src and dst addresses to establish >> a connection in a short time period. >> - A host can make use of ICMP error messages indicating that the >> src address should be this, or the src address is simply wrong. >> - A host can have cache for the reachability status, which stores >> which src and dst pair should be used to reach a certain dst. >> >> ** Pro >> - A connection can be established as far as one working pair exists. >> - Routing status can be reflected to address selection directly, >> which means no need for intermediate agent and information >> conversion. > > Missing a Pro that I consider significant: > > - Users will no longer experience multi-second connection delays due > to IPv6's address selection. This means more users will > leave IPv6 enabled. not due to IPv6's address selection, but due to IPv6 connection failure, aren't they ? >> ** Con >> - Impact for host protocol stack implementation. >> - Not a small change for the existing protocol stack and possibly >> applications. > > It's really the applications that have to change so that they > are more aggressively going through the getaddrinfo()-sorted > addresses to get a connection established. > >> - We do not have established caching algorithm. > > Not a problem caused by, or limited to, Fred's proposal. Ignoring Fred's > proposal for a second, RFC3484 address selection policies could be wrong (as > we all know) and perhaps they should be able to learn/notice failures. This is what I meant by the combination with Fred's proposal and policy distribution. Of course, it is beneficial to have this combination, but such caches are not essential for policy distribution way. >> - Caching does good for static environment, and can harm for >> dynamically changing environment. >> - Network outage invokes cache reconstruction. >> - Conformance with network policy, user experience. >> - A connection success does not mean conformance with site network >> policy, nor user experience, such as delay and bandwidth. >> - A site may have demands for preference control on address >> selection, >> such as IPv6 and IPv4 prioritization, in order to decrease network >> provisioning cost or to enhance user experience. >> - Extra load for network and host. >> - routers have to send error messages. >> - servers are loaded by unused sessions. >> - extra CO2 emission ;) > > That amount of extra traffic is tied to how caching and dynamic learning might > be specified. We could, if this is a sensitive issue, specify that things > work as slowly as today (e.g., multi-second second connection timeouts before > trying another IP address). However, this creates a very poor user experience > which today can only be resolved by the user disabling IPv6! We do not want > people disabling IPv6 to improve their user experience, but that is their only > choice today. There are so many reasons that makes users disable IPv6, such as network unreachability, and application IPv6 related mal-functioning,... This proposal does not solve all the cases. > >> - Non-connected transport protocol complexity >> - Only applications know the connection success/failure if they use >> non-connected transport protocol like UDP. > > Not a problem caused by, or limited to, Fred's proposal. I cannot get why. If the kernel caches address selection information, it has to have connection success/failure information. OTOH, if the appropriate policy is distributed, every application/protocols can make use of it. > >> - Spoils DNS round-robin based load balancing >> - Network side(routers) cannot have effects on dst address selection. >> Only can have effects on src address selection. >> >> >> * Design Team proposal. >> - Network side distributes address selection policy to hosts. >> >> ** Pro >> - No impact on protocol stack, as far as it implements RFC 3484. >> - At least, network policy can be implemented. >> This does not always lead to user experience enhancement. >> - Network side can have effects on dst address selection also. >> ** Con >> - Hosts have to have functionalito for receiving and processing policy >> information. >> - To make use of routing information, routing information has to be >> converted to address selection policy at intermediate nodes, and >> frequently updatable policy distribution mechanism is necessary, >> such as DHCP reconfigure. >> >> >> * Considerations towards next-step >> Design team proposal and Fred proposal have different applicability >> domains, and one does not include the other. >> Fred proposal works more nicely if combined with Design >> team'smechanism. >> Design team proposal can work by itself, but if combined with >> Fred proposal, the applicability will be broader. >> So, my suggestion is to have both mechanisms, while keeping >> one mechianism work without the other protocol. > > Sounds alright. > > -d -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
