________________________________________ From: ietf-bounces@xxxxxxxx [ietf-bounces@xxxxxxxx] On Behalf Of Sabahattin Gucukoglu [mail@xxxxxxxxxxxxxxxxxxxxxxxx] My thought right now is perhaps of an OS update that includes a background client which tries very hard to reduce the effect of breakage or delay caused by IPv6 routes that are dead, DNS queries that don't go anywhere, and delays caused by slow transition techniques. It couldn't be comprehensive, but I think it'd go a long way at this point. The software vendors could, for instance, provide the test sites that receive IPv6 probes and/or traffic, and respond to them. Not scalable? ... _______________________________________________ An interesting concept. It resembles ideas we've discussed but not implemented in our SIP stack: For any given SIP destination, there may be many SRV records that give various redundant servers for that SIP domain. Instead of obeying the SRV records as they are given, falling back from the one with highest priority to the next highest priority, etc., keep track of which addresses have recently been responding and which have not. Those that have not been responding have their SRV priority artificially lowered for the purposes of the address-selection algorithm. For addresses that need prompt response but are not accessed on a short cycle, a background process can send probes to keep the responsiveness information up to date. An interesting aspect of this that might allow it to be generalized (at least in regard to applications that search for SRV records before A records) is that this could be implemented in a shim between the DNS lookup interface that the SIP stack uses and the real DNS: The SRV records that the application sees can be modified to give the desired effect. And for SIP domain lookups that do not have SRV records, SRV records can be synthesized to give the desired effect. In particular, if a domain name has an A record and an AAAA record, instead of letting the application see (and choose between) these records directly: domain.example.com A xx.yy.zz.ww domain.example.com AAAA pppp::qqqq the shim could construct: _sip._tcp.domain.example.com SRV prio=1 weight=1 name=AAAA.domain.example.com port=5060 _sip._tcp.domain.example.com SRV prio=100 weight=1 name=A.domain.example.com port=5060 _sip._udp.domain.example.com SRV prio=1 weight=1 name=AAAA.domain.example.com port=5060 _sip._udp.domain.example.com SRV prio=100 weight=1 name=A.domain.example.com port=5060 A.domain.example.com A xx.yy.zz.ww AAAA.domain.example.com AAAA pppp::qqqq Thus, the shim has directed the SIP stack to try the IPv6 address first -- without any application change! Dale _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf