> > Well this is all moot as anycast addresses are not allowed to
> > be assigned to hosts and DNS service is host functionality.
>
> the condition "host cannot have anycast address" was introduced
> because, when RFC2373 was written, there seem to be no way for
> hosts to inject /128 routes to the site routing system. actually it is
> very easy to solve:
> - hosts with anycast address speak RIPng, OSPFv3 or whatever, and
> inject /128 route to the site routing system.
> - extension to MLD, draft-haberman-ipngwg-host-anycast-00.txt
> - configure a static route for anycast address (/128) onto the router
> adjacent to the anycast host.
> - run DNS server on a router (you can make a UNIX box a router,
> you know)
> the first bullet is very easy and can be tested with no protocol change
> .
> we have been using it quite a while.
>
> the condition "don't put anycast into source" was introduced because
> of tcp issues, as you've described.
>
> draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt describes it in full.
>
> > To get around the truncation and tcp fallback we could have
> > a EDNS option that specified a unicast address to use that
> > is sent back with the truncated response. Or do we just send
> > this EDNS response and force a switch to unicast regardless of
> > TC.
>
> yes, truncation and the fallback to TCP is a problem.
> here are a list of solutions i can think of on truncation/fallback
> issue:
> - clients should use EDNS0 and avoid most of the truncation cases.
> - TCP query should pick the destination address from the UDP reply.
> (possibility of hijack, of course)
>
I stand by my original answer as to the source address is
the anycast address for DNS.
RFC 2373 clearly expects this section to be potentially
overridden. You don't get dueling RFCs when the overriding
RFC acknowledges the one being overridden.
Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
