Charlie,
     I had actually started taking a crack at this whole problem.  It
seems to me that the following components are needed for some form of
global anycast support:

     1. Host-to-router notification protocol (this is taken care of by
        changes to mld proposed in draft-haberman-ipngwg-host-anycast)

     2. Security: at a minimum some form of authentication to allow
        routers to determine if hosts are allowed to join an anycast
        group

     3. An Anycast Architecture doc that pulls all the pieces together
        and concretely describes how pieces interact, the pros and cons
        of anycast usage for intra-domain and inter-domain

     4. Possibly a draft that documents any impacts on any existing
        protocols (routing protocols, TCP, etc.)

Now, I have not spent time on the subject in the last 4-5 months, so I
have not gotten much past this list.  It is crucial that most of the
issues raised by Itojun's anycast analysis draft be addressed.

It should also be noted that this is probably way too much work to do
in the IPv6 WG.

Regards,
Brian

"Charles E. Perkins" wrote:
> 
> Hello folks,
> 
> I think this is a great idea.
> 
> Furthermore, on the topic of letting packets have Source IP
> address be the address of an anycast group, I think that it's
> the responsibility of the particular anycast group to handle
> all the ramifications.  It would be nice to have an Internet
> Draft that lays out all of the canonical ramifications.
> 
> In the case where there is only one element of an anycast group,
> and it has one of the "well-known" anycast numbers on its subnet,
> this seems to be very natural and beneficial.  There would not
> be a need to make the restriction for short session lifetimes.
> 
> If the anycast group can have several members, but still is
> addressable at one of the "well-known" anycast numbers, then
> we can require a standard specification for the operation
> of the anycast group, including any such features as use of
> the anycast address as a Source IP value.
> 
> Similar considerations hold for security, and even mobility
> of the anycast group.  In fact, with enough calculation, we
> might even be able to find some CGA-able anycast groups within
> some lucky subnets!
> 
> Regards,
> Charlie P.
> 
> "Bound, Jim" wrote:
> >
> > I agree.  Lets begin to work on getting a SHOULD that would fix it completely.
> >
> > I will follow your lead in the WG so lets do it ............
> >
> > /jim
> >
> > > -----Original Message-----
> > > From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 02, 2002 2:28 AM
> > > To: Bound, Jim
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Anycast Addresses being used for Nodes not just Routers
> > >
> > >
> > > On Wed, 1 May 2002, Bound, Jim wrote:
> > > > What do we think we need to do to get the requirement that
> > > only Routers
> > > > can have anycast addresses changed to "nodes".
> > > >
> > > > IETF Work draft-yanjun-lbam-ipv6-00.txt is a good example
> > > of the use of
> > > > anycast for non-router systems that are very important for
> > > the Internet
> > > > and IPv6.
> > >
> > > I've been trying to push the changing of this:
> > >
> > >       o An anycast address must not be assigned to an IPv6 host, that
> > >         is, it may be assigned to an IPv6 router only.
> > >
> > > in addr-arch-v3-07 to change 'must' to a 'should' for some
> > > time now, with
> > > not much progress.
> > >
> > > I think this is one item that should be changed before
> > > addr-arch is done
> > > with in the IESG and locked for a few years.
> > >
> > > --
> > > Pekka Savola                 "Tell me of difficulties surmounted,
> > > Netcore Oy                   not those you stumble over and fall"
> > > Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> > >
> > >
> >
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to