________________________________________
From: ietf-bounces(_at_)ietf(_dot_)org [ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Sabahattin Gucukoglu [mail(_at_)sabahattin-gucukoglu(_dot_)com]
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf