Sorry for the late response.
True. It is also worth asking what is the proper granularity for storing
the binding: per host, per flow, or something in between? Do we want to
redirect all applications to the same unicast address, or should we
allow different flows go to different unicast
On Mon, 2003-03-10 at 16:46, Erik Nordmark wrote:
True. It is also worth asking what is the proper granularity for storing
the binding: per host, per flow, or something in between?
In most cases it shouldn't matter since the routing system will be stable
enough so that multiple
Well, this was only proposed for TCP.
I don't know what this refers to but the original message from Pekka
commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to
those comments.
That draft has this in the abstract:
Today, the use of IPv6 anycast is limited. This document
On Tue, 2003-02-25 at 15:28, Erik Nordmark wrote:
Well, this was only proposed for TCP.
I don't know what this refers to but the original message from Pekka
commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to
those comments.
That draft has this in the abstract:
TCP has the problem that it simply can't be used with an
anycast address
without changing the protocol or somehow handling the binding
transparently on L3 (as in MIPv6). UDP doesn't have this problem; at
most the applications need to be changed to react correctly to peer
On Tue, 2003-02-25 at 23:20, Hesham Soliman (EAB) wrote:
= Right, but I guess the latter type of application
would not be harmed by the extra security.
Performance?
MikaL
IETF IPng Working Group Mailing List
IPng
On Tue, 2003-02-25 at 23:20, Hesham Soliman (EAB) wrote:
= Right, but I guess the latter type of application
would not be harmed by the extra security.
Performance?
= In theory yes, but I don't know how significant
it will be. I suppose we need to see a complete
Depends what happens when the binding times out and
needs to be refreshed/re-established.
MIPv6 assumes that it can just redo the RR exchange and
still end up sending to the same host. That isn't the case for
anycast since the anycast address identifies more of a service than a host.
On Mon, 24 Feb 2003, Erik Nordmark wrote:
For connection-less protocols, source address should not matter, that
much.
The fact that UDP is a connection-less layer 4 protocol doesn't mean
that there aren't protocols above it which assume that they
continue to talk to the same peer (until
On Mon, 2003-02-24 at 16:57, Erik Nordmark wrote:
What about the case when you have UDP communication which needs to reach
the same server? (or at least be notified when the anycast server changes).
In that case you can't rely on the fact that the kernel has a single notion
of active
On Fri, 21 Feb 2003, Erik Nordmark wrote:
On the other hand, I'm very worried about specifying a host-router
protocol, as it is a new protocol -- contrary to working operational
practise -- and has a number of difficult issue to tackle with, most
important of them perhaps the
On the other hand, I'm very worried about specifying a host-router
protocol, as it is a new protocol -- contrary to working operational
practise -- and has a number of difficult issue to tackle with, most
important of them perhaps the security/authorization and interaction
with the
Not necessarily. The anycast,unicast binding could be stored in the
binding cache as in MIPv6 and TCP could continue using the anycast
address.
Depends what happens when the binding times out and
needs to be refreshed/re-established.
MIPv6 assumes that it can just redo the RR exchange and
On Fri, 2003-02-21 at 17:16, Erik Nordmark wrote:
Not necessarily. The anycast,unicast binding could be stored in the
binding cache as in MIPv6 and TCP could continue using the anycast
address.
Depends what happens when the binding times out and
needs to be refreshed/re-established.
Hello,
Sorry for the delay in responding.
On Tue, 18 Feb 2003, Erik Nordmark wrote:
1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using
MLD) -- May 2002.
== basically the MLD protocol is used to signal anycast joins/leaves.
However, critical part which seems to be
1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using
MLD) -- May 2002.
== basically the MLD protocol is used to signal anycast joins/leaves.
However, critical part which seems to be missing here is interactions of
anycast-MLD with routing, as with multicast.
There
Mika Liljeberg wrote:
Hi Brian,
On Wed, 2003-01-29 at 00:03, Brian Haberman wrote:
The RR mechanism for anycast already requires the ability to use
the anycast address as a source address. If we can get agreement
on lifting that restriction, I like the idea of keeping changes
out of TCP.
On Wed, 2003-01-29 at 01:28, [EMAIL PROTECTED] wrote:
Well you don't actually want it lifted. You don't want a
anycast address being used to *initiate* a transaction.
Why not?
You do however want to be able to *reply* using the anycast
address. For UDP this is will
On Wed, 2003-01-29 at 13:23, Brian Haberman wrote:
Mika Liljeberg wrote:
I just spotted the following: the RR mechanism sends HoT to the anycast
address. How does that work? It might go to a completely different
server.
There is an assumption that there won't be a routing change on
the
Mika Liljeberg wrote:
On Wed, 2003-01-29 at 13:23, Brian Haberman wrote:
Mika Liljeberg wrote:
I just spotted the following: the RR mechanism sends HoT to the anycast
address. How does that work? It might go to a completely different
server.
There is an assumption that there won't be a
On Wed, 2003-01-29 at 19:52, Brian Haberman wrote:
I'm just wondering if this holds true for load balancers. For
transaction type application one might want to send each connection to a
different server.
The load balancer that I am aware of would actually use the source
address of the
Susceptibility to DoS attacks is another consideration that needs some
attention, I think. The RR mechanim in MIPv6 is designed to require no
state in CN, but in the anycast RR mechanisms the roles are reversed:
here the anycast server is the one holding state.
Is that really true? What about
On Wed, 2003-01-29 at 20:19, Brian Haberman wrote:
However, you could flood the anycast server with RR state simply by
sending a lot of SYN packets with different forged source addresses.
Doesn't MIPv6 have the same problem with flooding an MN with bogus
data as a DoS attack? Casting
On Wed, 2003-01-29 at 01:28, [EMAIL PROTECTED] wrote:
Well you don't actually want it lifted. You don't want a
anycast address being used to *initiate* a transaction.
Why not?
Because the reply traffic is *not* guaranteed to go back
to the same instance. The
On Thu, 2003-01-30 at 00:16, [EMAIL PROTECTED] wrote:
On Wed, 2003-01-29 at 01:28, [EMAIL PROTECTED] wrote:
Well you don't actually want it lifted. You don't want a
anycast address being used to *initiate* a transaction.
Why not?
Because the reply traffic is *not*
On Thu, 2003-01-30 at 00:16, [EMAIL PROTECTED] wrote:
On Wed, 2003-01-29 at 01:28, [EMAIL PROTECTED] wrote:
Well you don't actually want it lifted. You don't want a
anycast address being used to *initiate* a transaction.
Why not?
Because the reply
On Thu, 30 Jan 2003 [EMAIL PROTECTED] wrote:
The socket option doesn't help. If an application doesn't understand
anycast addresses and tries to use one as a source address, it will fail
regardless of whether there is a socket option for it or not.
No it will work intermittently
On Tue, 2003-01-28 at 08:33, Pekka Savola wrote:
TCP has to be modified anyway, I see no way around that.
Even with RR mechanism, TCP has to be modified to reconnect to the new
unicast address. This is basically the same.
Not necessarily. The anycast,unicast binding could be stored in the
On 28 Jan 2003, Mika Liljeberg wrote:
On Tue, 2003-01-28 at 08:33, Pekka Savola wrote:
TCP has to be modified anyway, I see no way around that.
Even with RR mechanism, TCP has to be modified to reconnect to the new
unicast address. This is basically the same.
Not necessarily. The
On Tue, 2003-01-28 at 22:13, Pekka Savola wrote:
Not necessarily. The anycast,unicast binding could be stored in the
binding cache as in MIPv6 and TCP could continue using the anycast
address.
That would require anycast be used as source address, or home address
option, right? (Plus
Hi Brian,
On Wed, 2003-01-29 at 00:03, Brian Haberman wrote:
The RR mechanism for anycast already requires the ability to use
the anycast address as a source address. If we can get agreement
on lifting that restriction, I like the idea of keeping changes
out of TCP.
I just spotted the
The RR mechanism for anycast already requires the ability to use
the anycast address as a source address. If we can get agreement
on lifting that restriction, I like the idea of keeping changes
out of TCP.
Well you don't actually want it lifted. You don't want a
anycast
I have a hard time seeing anycast TCP used in the global network or
beyond selected applications in local networks. That being the case,
requiring that the client hosts to support MIPv6 route optimisation
(with some tweaks) should not be that big a deal.
MikaL
Well the
I happened to read through a few older anycast-related drafts; a few
comments, to try to spark some discussion on how to go forward with
anycast. Last, I bring up one idea how to possibly make TCP+anycast work,
in relatively simple terms.
1) draft-haberman-ipngwg-host-anycast-01.txt
On Mon, 27 Jan 2003, Brian Haberman wrote:
There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers. Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust) an IGP/iBGP area -- a
Pekka Savola wrote:
On Mon, 27 Jan 2003, Brian Haberman wrote:
There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers. Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust) an IGP/iBGP
Hi Pekka,
On Mon, 2003-01-27 at 17:40, Pekka Savola wrote:
On Mon, 27 Jan 2003, Brian Haberman wrote:
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
On 27 Jan 2003, Mika Liljeberg wrote:
I agree with you here .. but ICMP could give you enough strong
authorization with basically zero added messages.
Not necessarily. If the TCP anycast server were to send the ICMP
back-to-back with the SYN-ACK, any reordering in the network would
Hello,
I happened to read through a few older anycast-related drafts; a few
comments, to try to spark some discussion on how to go forward with
anycast. Last, I bring up one idea how to possibly make TCP+anycast work,
in relatively simple terms.
1) draft-haberman-ipngwg-host-anycast-01.txt
39 matches
Mail list logo
