Re: the well-known address approach

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 7 Aug 2003, Ralph Droms wrote:
> I really did mean to talk about unicast as opposed to any kind of anycast,
> because the most recent published description of a scheme for using
> well-known addresses to access DNS service
> <draft-ietf-ipv6-dns-discovery-07.txt> specifies unicast.  If I remember
> correctly, the earlier discussion about well-known addresses progressed from
> specifying anycast to unicast because of concerns that "just propagate host
> routes to those service addresses in the internal routing" might prove to be
> complicated in practice.

The argument I've heard a lot is one of architectural purity, as the 
address architecture states (for example):

--8<--
2.6 Anycast Addresses
                                                                                                                         
   An IPv6 anycast address is an address that is assigned to more than
   one interface (typically belonging to different nodes), with the
   property that a packet sent to an anycast address is routed to the
   "nearest" interface having that address, according to the routing
   protocols' measure of distance.
                                                                                                                         
   Anycast addresses are allocated from the unicast address space, using
   any of the defined unicast address formats.  Thus, anycast addresses
   are syntactically indistinguishable from unicast addresses.  When a
   unicast address is assigned to more than one interface, thus turning
   it into an anycast address, the nodes to which the address is
   assigned must be explicitly configured to know that it is an anycast
   address.

[...]
--8<--

I.e. that any address which is allocated in more than one interface turns 
into an anycast address... and there can be _no_ "nearest-unicast" 
addresses at all.

Needless to say I disagree with this model... :-)

> At 03:54 PM 8/7/2003 +0300, Pekka Savola wrote:
> >On Thu, 7 Aug 2003, Ralph Droms wrote:
> > > I believe there is also a scaling issue.  If the well-known address
> > > mechanism is truly limited to unicast (and not anycast) addressing, an
> > > enterprise can only deploy as many recursive name servers as there are
> > > reserved, well-known addresses.
> >
> >It depends on what you mean by "anycast" here.
> >
> >If well-known addresses are shared-unicast addresses (by the terminology
> >of draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt), it might go easier.
> >
> >You could just deploy the same (service) address in a lot of different
> >nodes, and just propagate host routes to those service addresses in the
> >internal routing; so, there could be more servers, but based on one node's
> >temporal view of the topology, it could only see N (e.g. three) at the
> >time and the place.
> >
> > > Another potential issue is that deployment of hosts using the well-known
> > > addresses will force network operators to support DNS service at those
> > > well-known addresses, even if some other service architecture would be
> > > better suited to that network's requirements.
> >
> >Agreed, this may be an issue.  However, just as well you could redirect
> >all of those to a box (even a router) which could proxy those requests to
> >some otherwise configured DNS servers.
> >
> >--
> >Pekka Savola                 "You each name yourselves king, yet the
> >Netcore Oy                    kingdom bleeds."
> >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> #----------------------------------------------------------------------
> # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.