>> 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.
ok, will think about the section title. >> 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? yes. >> 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. then how can we make servers and clients interact? >> 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. i don't think so. you can say the same thing about routers - one would want certain router to be able to inject certain routes only, not the default route/whatever. there's no such protocol available today. (s-bgp?) itojun -------------------------------------------------------------------- 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] --------------------------------------------------------------------