> >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. > > if "shared-unicast address" is more common, i'm happy to use that term.
I don't know if that term is widely used, but I think it makes sense defining it in the document and using it. > i'll update the draft to refer RFC3258 and make necessary adjustments. > i'm not sure if i should keep references to mohta-san's draft. I think it's fine to keep the reference as long as you explain the salient issues. > i guess title of section 3 was vague - "current proposals" tries to mean > "current proposals made for IPv6", like RFC2373 limitation for IPv6 > anycast address assignment. therefore, 3.3 talks about restriction > imposed by RFC2373, which is applicable to IPv6 only. > i'll update title of section 3 to be more clear, and make sure to > remove any IPv4 topic from section 3. But RFC 2373 is more than a proposal - it is the IPv6 addressing architecture. Even if some folks might want to change it I think it can be confusing to calling it a proposal - the "current state of IPv6 anycast architecture" might be more accurate since it indicates potential future changes without treating it as merely a proposal. > the paragraph tries to say: > - if we use predefined site-local anycast address, the propagation of > host route (/128) would be limited within the site, therefore it may > be permissible (depending on the routing table size of the site) or they might even be aggregated at an IGP area boundary... > - if we use predefined global anycast address, host route needs to be > carried worldwide and we will see problems like you mentioned above. > > how should i word it for clarity? Point out in section 1 that anycast addresses have route scalaing issues. If anycast addresses are drawn from the unicast address space (as is the case in IPv6 and the IPv4 DNS anycast) the routing scaling impact can potentially be limited by aggregating the anycast addresses as part of the regular unicast routing prefixes. But this aggregation can only be applied when all members in the anycast group remaing within the piece of toplogy whose routes get aggregated. For instance having an anycast address where all the members belong to one ISP means it the anycast address can be drawn from the ISPs address space and be aggregated at the ISP boundary with no effect on route scaling outside that domain. But having e.g. anycast groups with members across the whole Internet will have effect on the size of the routing tables globally. Does that capture what you want to say? > >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. > > quoting RFC2181: > >> will be able to use it for further queries. Servers configured in > >> such a way that not all their addresses are equally reachable from > >> all potential clients need take particular care when responding to <--- > >> queries sent to anycast, multicast, or similar, addresses. <--- > from the above text, it is clear that client should/can not check the > source address of the reply in the above case. Your notion of clarity seems quite different than mine. Section 4 in 2181 is about server behavior with recommendations on how to make servers work with a large range of different client behavior. But that doesn't mean that you can infer recommended or required client behavior from that section. > routers will know that the host is authorized to inject a route to > the routing system, by the fact that it knows the shared secret > used by the routing protocol (if the route is advertised with proper > authentication encapsulation/extension header, it is authorized). > do i need to be more clear on such trivial thing? if so, how? But if the host knows the shared secret used by the routing protocol it can inject any route (e.g. default or some other prefix). For anycast presumably one would want to restrict the host to only inject a particular host route. 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] --------------------------------------------------------------------
