On Mon, 26 Sep 2005, Hallam-Baker, Phillip wrote: > > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > > Behalf Of Tim Bray > > > On Sep 24, 2005, at 8:28 PM, Dean Anderson wrote: > > > > > None of my emails have been abusive. > > > > Speaking as a 99.99999999% passive observer around here, I consider > > Dean Anderson's emails, in aggregate, abusive. They consume precious > > mental bandwidth, in many cases with no material technical content, > > and thus make it more difficult for me (and I assume many others) to > > follow the flow of IETF discussion. > > I am completely unable to follow the line of argument. > > Dean appears to be claiming that DNSSEC is somehow incompatible with the > widespread use of anycast. If for the sake of argument we accept this as > true the only conclusion I could draw from such a situation is that > DNSSEC would have to be sent back to be reworked again. If DNSSEC does > not support existing use cases then it has to be fixed. It is not DNSSEC that is broken. > But I do not see how DNSSEC is incompatible with anycast. It is merely > an assertion that is repeated without evidence. Anycast might possibly There has been plenty of evidence on the DNSOP list and most recently on the GROW list. Without getting into to much detail, Anycast doesn't work with TCP, but it also doesn't work with large UDP packets and fragments. DNSSEC requires large UDP packets and fragments. The details of why fine grained load balancing permitted by RFC1812 break the Anycast Extension are hinted at in RFC1546 and the footnotes to my instant criticism on DNSOP. I can send you a more detailed explanation if you like offlist. Your assumption below is common: You assume that everyone does course grained load balancing or no load balancing. Besides RFC1812 permitting fine grained load-splitting in "theory", Cisco implements it. There are active programs underway such as BGP multipath, which also results in fine grained load-splitting. One cannot assume that two successive packets are delivered to the same path or that two successive packets will reach the same Anycast destination. This is acceptable for small, stateless UDP packets. It is not acceptable TCP or large UDP packets and fragments. > break TCP/IP fallback but it is unlikely that the anycast routes would > change rapidly enough for that effect to be any more significant than > existing TCP issues created by firewalls. > > Cryptography is remarkably indifferent to transport, this is the biggest > challenge in the DKIM spec. Depending on particular transport > configurations has in the past turned out to be a mistake. The > authentication of the end point IP addresses in IPSEC achieves no useful > security purpose, it only causes the protocol to become more brittle in > use. > > If the issue is real then it should be raised in DNSEXT where the DNSSEC > specs are being developed. It does not appear to be genuine to me. Its not a problem with DNSSEC per se. It a problem with operation of Anycast Root Nameservers. There should not be any Anycast root nameservers. > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf