I've finally re-reviewed draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt. I have some concerns about clarity as well as strong concerns about the document seeming to change the standard for DNS clients verifying the source address of the replies. Details below.
RFC 3258 uses the term "shared-unicast address" for what you seem to be calling "pseudo-anycast". I wonder if it makes sense using this existing term instead of creating a new one. RFC 3258 talks about an organization using anycast internally while speaking BGP to the external world, yet in section 2.2 you bundle this with draft-ietf-dnsop-ohta-shared-root-server-02.txt and seem to say that they both cross AS boundaries. As I understand it the technical difference between 3258 and shared-root-server is whether it is contained within one AS or not. Thus it would make sense to make this more clear in the document. Currently section 2.2 seems to only speak about the ohta approach, and my understanding is that the RFC 3258 approach is more widely deployed for DNS. I think RFC 3258's shared-unicast approach is quite useful given the constraints it imposes on itself: - used for DNS lookups i.e. short transactions - that the DNS has a failure recovery mechanism (through multiple NS records and multiple nameservers in resolv.conf) which provides failure recovery even though the routes are not withdrawn when an instance of the shared-unicast service dies. To make this more clear you can either remove the mention of BGP and "distant domains" from section 2.2 or you can make it clear what the Hardie and Ohta-san documents have in common and what is different (with the "distant domains" being the difference). I think it would be very useful to point out in section 3.3 that there is nothing inherent in IPv6 that prevents the use of pseudo-anycast - the issues listed in section 3.4 apply to both IPv4 and IPv6. I don't think there is WG concensus to endorse such behavior for IPv6 even through the scheme used in the Hardie and Ohta-san documents would work just as well (or poorly) in IPv6 as in IPv4. I don't understand what the last paragraph in section 4.1 is trying to say. Clearly carrying /128 routes for anycast word-wide doesn't scale for arbitrary use of anycast (but having explicit routes e.g. for DNS root servers isn't an abitrary use since the set of addresses would be very limited). Whether site-locals or globals are used it is required that the anycast addresses aggregate into existing prefix routes at some scale. But is the paragraph trying to say that this is some improvement that is needed? (It is in a section about possible improvements.) It can be read as this being something that needs to be fixed, but I think it is just a fundamental constraint whether anycast addresses are assigned to only routers or also to hosts. Thus the point seems to belong in section 1. Section 5.1 says: Note that, however, bad guys can still inject fabricated results to the client, even if the client checks the source address of the reply. The check does not improve security of the exchange at all. This seems counter to the wisdom that lead to requiring the addresses to match, yet you don't refute those arguments. I think in reality the (very spotty but existing) application of ingress filtering in the 'net means that the DNS requirement on matching addresses in requests and replies provide a non-zero security improvement. I think it is a bad idea to have an informational document like this try to change the DNS protocol practise to not check the source address of the reply. If you want to change this we need a standards track document. Having this informational document discuss the issue of source address checking is fine, but it isn't fine that it effectively removes it. o For many of the existing protocols, we cannot perform sanity checks using IP source address address. More specifically, for UDP DNS replies against queries to anycast address, it is not recommended to check source address, based on RFC2181 section 4.1. I don't see any text in section 4.1 in 2181 that recommends changing anything on the client. In fact section 4 and 4.1 is how to make servers work with clients that do verify the source address of the reply. Thus I can't see how you come to this conclusion. Section 7: For secure anycast operation, we may need to enable security mechanisms in other protocols. For example, if we were to inject /128 routes from end hosts by using a routing protocol, we may need to configure the routing protocol to exchange routes securely, to prevent malicious parties from injecting bogus routes. "exchange routes securely" reads like securing the exchange of the routes between the host and the router. That is useful but inadequate. The difficult problem is how the router knows which host is *authorized* to inject a route for which anycast address. Securing the communication between the host and router doesn't solve the authorization problem. It would make sense to point this out as an unsolved problem (short of manual configuration) in the draft. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
