Let me re-send the following e-mail. It did not make it to 6man ml web archive.
--- Hi, >>> >>> 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 ? > > The connection failure is caused by incorrect address selection. > > I don't see how to separate the two. > > And users don't care -- they simply disable IPv6 if it slows > down their experience. > >>>> ** 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. > > I am hoping to reduce reasons that users might disable IPv6. Agree. > >>>> - 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. > > Yes, and that works even for UDP: > > a. the OS can see an incoming UDP response packet, > because almost every protocol is a request/response protocol almost every, but not every protocol. And, that does not mean almost every user does not experience this problem. > or: > b. the OS can see the application gave up on one socket > and is trying another socket. This indicates the application > was -- for whatever reason -- 'displeased' with the address > selection made by the OS. This looks another troublemaking mechanism. Can the operating system really tell it's application gave-up or successful socket close ? > (b) seems implementable in the OS, and seems appealing. I cannot see it's implementable without any harm. Kindest regards, >> 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: arif...@nttv6.net >> > -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arif...@nttv6.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
