>> 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]
--------------------------------------------------------------------
