On Mon, 27 Jan 2003, Brian Haberman wrote:
> >>The big issue is with inter-site anycast. A host route from a foreign
> >>domain (i.e. not the prefix owner) could actually prevent anycast
> >>traffic from reaching the owning domain unless explicit config allowed
> >>for the "leaking" of the host route out of the home domain.
> >
> >
> > I see this as something that should be explicitly defined out-of-scope for
> > these kind of anycast mechanisms.
>
> So would I, except it is supported today in v4.
Well, it's supported today with IPv6. It just isn't automatic. As with
IPv4.
> > The unicast address. The point is to restrict those who can join to a
> > group to only a few, legal unicast addresses. And that those MLD joins to
> > a group using unicast address X would actually require that X would be
> > routed to the interface/subnet from where the MLD join came from
> > (otherwise -> bombing/DoS attacks).
> >
> > Or was there some misunderstanding..?
>
> It sounds like you want to restrict anycast members to a single
> link or that an anycast prefix has to be configured on multiple
> interfaces around the network.
I don't understand what you're saying, so let me try to clarify.
If node X wants to join an anycast group G with unicast address U_x, there
will have to be explicit authorization for (U_x, G); further, further the
report for (U_x, G) must come from an interface for which U_x is reachable
-- that is, where (loose) uRPF route points to.
Node Y could not report (U_x, G) from node Y's link unless U_x would be
routed there. Node Y could not report (U_y, G{_any}) either unless
authorized by explicit configuration.
> > Depends on the scope, of course. To me, exchaning 7+3 messages just to
> > open a TCP session seems like a lot. Especially when most, effective
> > anycast+TCP traffic should be short-lived (so routing changes do not
> > become a significant problem).
> >
> > OTOH, anycast is currently applicable in site-internal traffic only where
> > you can expect low network latency, ie no big problems except for the
> > packet overhead.
>
> So, for intra-site the extra messages are OK but not for inter-site
> anycast?
Well, I'm not sure whether conclusions could be drawn based on this, but
in intra-site traffic the overhead in setting up a TCP session probably
would not be noticeable.
> >>>3) that's it.
> >>>
> >>>My own, very raw idea for anycast + TCP: a new ICMP message, including the
> >>>seq number (or equivalent protocol-specific information) of the
> >>>just-received TCP SYN, indicating the unicast address which should be used
> >>>instead of the included anycast address.
> >>
> >>My original thought was to signal back the mapping using ICMP. The
> >>mapping authentication capability of the RR procedure gives a better
> >>level of security than a plain ICMP message.
> >
> >
> > I agree with you here .. but ICMP could give you enough strong
> > authorization with basically zero added messages.
>
> In order for the client to verify the authentication information in
> the ICMP message, we would need a key distribution mechanism.
No. ICMP would contain critical parts of the TCP header, including TCP
sequence number. This, and the state the initiator has about that
particular connection would be enough.
> > Well, anycast doesn't seem to be progressing otherwise, but I'm not sure
> > whether there's enough push for it (ie. could it be required by enough
> > autoconfiguration etc. mechanisms to be worth the effort).. the only I
> > could see it going forward would be as a separate WG.
> >
>
> The big issue is how will anycast be used. In general, I see it as a
> discovery mechanism. Once an anycast server responds, the client uses
> the server's unicast address for communication.
>
> Other views?
I think the whole concept of anycast needs a bit clarification.
One area of applicability would be to replace these interdomain
"BGP-anycast" -mechanisms with something like this (to make it possible
to identify who you're speaking to etc.), but that's a difficult problem,
probably not worth pursuing.
That leaves us basically with a discovery mechanism for site/ISP-internal
services. This would be mostly beneficial with something like site-local
addressing, for hardcoding addresses: when you already have to know the
prefix, it isn't all that much use to use anycast to discover e.g. DNS
servers when you already have to configure the prefix.
The third area of applicability would be providing failover/high
availability services for a service. The anycast seems like an option but
not really bringing much new to the discussion.
I guess the situation with IPv6 anycast is partially blurred by our
current trend of using IGP/BGP advertisement tricks to create
pseudo-anycast addresses. If these did not exist, there would be a lot
more to do. One possibility, of course, would be to try to get some added
value from there: e.g. by trying to make using such services easier with
stuff like MLD, create an API so when app would crash the service would go
on, etc.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
