> On Fri, 22 Apr 2005 00:24:19 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
>> I generally agree with the change, but I'm afraid a fresh reader of
>> this RFC-to-be will wonder about the removal, comparing to RFC3315.
>> So it would be nice to provide at least a pointer to relevant
>> di
Jinmei,
> Is everyone else OK with this proposed change?
I generally agree with the change, but I'm afraid a fresh reader of
this RFC-to-be will wonder about the removal, comparing to RFC3315.
So it would be nice to provide at least a pointer to relevant
discussion/drafts.
Good point.
I will add an
(Sorry for the long delay for this thread. I've been off-list for a
vacation.)
> On Thu, 14 Apr 2005 10:33:45 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
>> Anycast is complicated, and the complications are not specific to
>> IPv6. It really would be doing the world a favor if the IP
At Thu, 14 Apr 2005 10:33:45 -0700, Bob Hinden wrote:
> ...
> The proposal is then to remove the following text from the end of Section
> 2.6 the document:
>
> There is little experience with widespread, arbitrary use of Internet
> anycast addresses, and some known complications and hazar
Seems logical to me as well. If multicast is a specialized and complicated
topic worthy of a separate RFC, I can easily accept that anycast should be
given equal rights.
Bert
> -Original Message-
> From: Bob Hinden [mailto:[EMAIL PROTECTED]
>
> Rob,
>
> >Anycast is complicated, and t
On 14 Apr 2005, at 13:33, Bob Hinden wrote:
The proposal is then to remove the following text from the end of
Section 2.6 the document:
There is little experience with widespread, arbitrary use of
Internet
anycast addresses, and some known complications and hazards when
using them in th
Rob,
Anycast is complicated, and the complications are not specific to
IPv6. It really would be doing the world a favor if the IPv6 WG were
to get rid of the language in the IPv6 address architecture doc that
places IPv6-specific restrictions on anycast, then let the GROW WG
handle the general any
At Thu, 14 Apr 2005 09:32:47 -0400, Brian Haberman wrote:
>
> > Anycast is complicated, and the complications are not specific to
> > IPv6. It really would be doing the world a favor if the IPv6 WG were
> > to get rid of the language in the IPv6 address architecture doc that
> > places IPv6-speci
Hi Rob,
On Apr 13, 2005, at 23:32, Rob Austein wrote:
Upon further analysisI agree with Joe. I was trying to meet Bob
halfway, but upon reflection have concluded that I was wrong to do so.
Anycast is complicated, and the complications are not specific to
IPv6. It really would be doing the wor
On 13 Apr 2005, at 21:06, Rob Austein wrote:
So the criteria here are:
a) Short-lived session (typically two packet UDP exchange, but some
argue that even a fast 7 packet TCP exchange is ok, so long as it's
fast);
For the record, I know of people who have distributed video streaming
services
Upon further analysisI agree with Joe. I was trying to meet Bob
halfway, but upon reflection have concluded that I was wrong to do so.
Anycast is complicated, and the complications are not specific to
IPv6. It really would be doing the world a favor if the IPv6 WG were
to get rid of the lang
Hi Bob,
On 13 Apr 2005, at 17:13, Bob Hinden wrote:
Arbitrary use of Internet anycast addresses is not recommended.
There
are known complications and hazards when using them in their full
generality [ANYCST]. Specific usage guidelines are:
1) Anycast may be used for simple query
At Wed, 13 Apr 2005 14:13:34 -0700, Bob Hinden wrote:
>
> Here is a proposal (rough) based loosely on Fred Baker's proposal and
> subsequent discussion on the list:
>
> Arbitrary use of Internet anycast addresses is not recommended. There
> are known complications and hazards when using
Hi,
[Document author hat on]
Interesting discussion. Sorry for not responding to this thread, but I
have been dealing with a family matter and wasn't staying current with email.
I think there is general agreement that we can relax the anycast rules
specified the address architecture. The relev
Hi Erik,
On Apr 8, 2005, at 19:41, Erik Nordmark wrote:
Brian Haberman wrote:
o An anycast address MAY be used as the source address of an IPv6
packet.
o An anycast address MAY be assigned to an IPv6 host.
This change will allow users to operate IPv6 anycast services in the
same
man
At Sun, 10 Apr 2005 23:10:57 -0700, Erik Nordmark wrote:
>
> Sounds like my suggestion above needs to be clarified in that it doesn't
> prohibit fragmentation.
Yep.
Probably best just to say that we don't know how to do Path MTU
discovery with anycast source address and point to the text in oth
Rob Austein wrote:
At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote:
1. Add text to say "SHOULD limit packets with an anycast source to 1280
bytes". Add note that ICMP-based tools don't work with an anycast
source address.
Unless, of course, the application protocol in question happen
> > Applying IPsec doesn't help solve the authorization issue of who
> > should be allowed to receive packets sent to a particular anycast
> > address.
>
> Can you tell me any address or type of address for which that is an
> objective either of internet routing or addressing?
>
It is possible to
At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote:
>
> 1. Add text to say "SHOULD limit packets with an anycast source to 1280
> bytes". Add note that ICMP-based tools don't work with an anycast
> source address.
Unless, of course, the application protocol in question happens to be
Fred Baker wrote:
On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:
Applying IPsec doesn't help solve the authorization issue of who
should be allowed to receive packets sent to a particular anycast
address.
Can you tell me any address or type of address for which that is an
objective either of
On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:
Applying IPsec doesn't help solve the authorization issue of who
should be allowed to receive packets sent to a particular anycast
address.
Can you tell me any address or type of address for which that is an
objective either of internet routing or
Fred Baker wrote:
The mobility model that Joe and I discussed requires a security
association to be set up with the anycast address (IPSEC management
protocols reply with the anycast address as a source), supply a COA, and
then TCP is set up to the COA.
FWIW if you believe that routing is trustw
James Kempf wrote:
Correct. However, the v6 addressing spec prohibits the use of an
anycast address from being used as the source address in a datagram, or
being bound to an interface on a host. These two restrictions
effectively prohibit the use of anycast as a service distribution
mechanism.
Brian Haberman wrote:
o An anycast address MAY be used as the source address of an IPv6
packet.
o An anycast address MAY be assigned to an IPv6 host.
This change will allow users to operate IPv6 anycast services in the same
manner in which they do today with IPv4 anycast.
If we do th
On 7 Apr 2005, at 14:02, [EMAIL PROTECTED] wrote:
Do you have any concerns that relate to using an anycast address as
the
*source*?
What keeps 2 different hosts from using the same anycast address? If
they both talk to the same destination address tuple (a different
anycast address but 2 differe
> Do you have any concerns that relate to using an anycast address as the
> *source*?
What keeps 2 different hosts from using the same anycast address? If they both
talk to the same destination address tuple (a different anycast address but 2
different hosts) can't there be problems?
Seems
OK.
I can go with Brian's first bullet. That said, since any other unicast
address may be used as a source address, I wonder whether it would be
more useful to simply remove the bullets.
On Apr 7, 2005, at 9:55 AM, Joe Abley wrote:
On 7 Apr 2005, at 12:23, Fred Baker wrote:
My problem is that th
On 7 Apr 2005, at 12:23, Fred Baker wrote:
My problem is that the current text precludes the grow work. I am not
trying to specify it; I am trying to permit it.
Remind me what Brian's original text proposal was?
In my note to the IESG, I requested that the following text in
draft-ietf-ipv6-addr-
My problem is that the current text precludes the grow work. I am not
trying to specify it; I am trying to permit it.
Remind me what Brian's original text proposal was?
On Apr 7, 2005, at 12:23 AM, Rob Austein wrote:
At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
proposed text...
While I ap
ustein" <[EMAIL PROTECTED]>
To: "Fred Baker" <[EMAIL PROTECTED]>
Cc: "Margaret Wasserman" <[EMAIL PROTECTED]>; "IPv6 WG"
Sent: Thursday, April 07, 2005 12:23 AM
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
> At Wed, 6 Apr 2005
rman" <[EMAIL PROTECTED]>;
"Bob Hinden" <[EMAIL PROTECTED]>; "IPv6 WG" ; "Joe Abley"
<[EMAIL PROTECTED]>
Sent: Wednesday, April 06, 2005 9:50 PM
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt
>
> > OK, so then lets
On 7 Apr 2005, at 03:23, Rob Austein wrote:
At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
proposed text...
While I appreciate the effort that Fred put into crafting text, I'd
prefer Brian's original proposal.
To further paraphrase Rob's comments here, there is a lot to think
about when cons
At Wed, 6 Apr 2005 23:50:52 -0700, Fred Baker wrote:
>
> proposed text...
While I appreciate the effort that Fred put into crafting text, I'd
prefer Brian's original proposal. The only parts of this set of
anycast issues that's specific to IPv6 are the restrictions that the
IPv6 address architec
proposed text...
Replace
o An anycast address must not be used as the source address of an
IPv6 packet.
o An anycast address must not be assigned to an IPv6 host, that
is, it may be assigned to an IPv6 router only.
with
- An anycast address is used for very short exchan
Brian,
> I am soliciting input on a proposal to modify the rules defined
> in the current addressing architecture draft with respect to anycast.
> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change
> the following text in the addressing architecture:
>
>o An anyc
> OK, so then lets go back to the question posed in the thread. The
> current spec says that one should never use an anycast address as a
> source address under any circumstances. That clearly flies in the face
> of present practice, isn't responsiv to the set of concerns you raised
> about an
OK, so then lets go back to the question posed in the thread. The
current spec says that one should never use an anycast address as a
source address under any circumstances. That clearly flies in the face
of present practice, isn't responsiv to the set of concerns you raised
about anycast in ge
One of my collegues pointed out I wasn't clear enough.
The restictions on using a anycast address as a packet
source definitely need to be relaxed.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
>
> On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:
>
> > Getting back to unicast initiated sessions I would still
> > like to see some mechanism (as low in the stack as possible)
> > which would allow long running session to survive routing
> > changes.
>
> You're speaking in t
On Apr 6, 2005, at 6:36 PM, Mark Andrews wrote:
Getting back to unicast initiated sessions I would still
like to see some mechanism (as low in the stack as possible)
which would allow long running session to survive routing
changes.
You're speaking in this thread. Di
> To be honest, I can't imagine a routing protocol that does anything
> similar to prefix aggregation carrying tags around for individual /32
> or /128 addresses.
It wouldn't have to be for a /32. Take the root servers for
example. Tagging the /24 they each live in would be su
To be honest, I can't imagine a routing protocol that does anything
similar to prefix aggregation carrying tags around for individual /32
or /128 addresses. And while it is conceptually possible to do
per-packet load balancing, very few routers are actually configured
that way, because the end
> > > An IPv6 anycast address is indistinguishable from an IPv6 unicast
> > > address. As such, any rule prohibiting the use of an anycast address
> > > in any location is unenforceable - I have no way to identify an
> > > anycast address to apply the rule.
> >
> > Correct. However, the v6 add
> > An IPv6 anycast address is indistinguishable from an IPv6 unicast
> > address. As such, any rule prohibiting the use of an anycast address
> > in any location is unenforceable - I have no way to identify an
> > anycast address to apply the rule.
>
> Correct. However, the v6 addressing spec
On 6 Apr 2005, at 16:09, Manfredi, Albert E wrote:
Any reason why the same rules that apply to multicast addresses
wouldn't also work here?
Actually, yes.
Anycast is being used to deploy services which, to clients, appear
identical to normal unicast services. The protocols used are varied,
and w
On Apr 6, 2005, at 15:12, Joe Abley wrote:
On 6 Apr 2005, at 14:50, Fred Baker wrote:
Define "anycast address" in this question?
A single unicast address bound to multiple interfaces.
An IPv6 anycast address is indistinguishable from an IPv6 unicast
address. As such, any rule prohibiting the use o
Fred,
On Apr 6, 2005, at 14:50, Fred Baker wrote:
Define "anycast address" in this question?
An IPv6 anycast address is indistinguishable from an IPv6 unicast
address. As such, any rule prohibiting the use of an anycast address
in any location is unenforceable - I have no way to identify an
a
doesn't work. When TCP sends a SYN to the anycast address, it can only
identify the SYN-ACK by having the source address of the SYN-ACK be the
anycast address.
The mobility model that Joe and I discussed requires a security
association to be set up with the anycast address (IPSEC management
pr
At Wed, 6 Apr 2005 13:22:58 -0400, Brian Haberman wrote:
>
> There is a proposal in draft-jabley-v6-anycast-clarify-00.txt to change
> the following text in the addressing architecture:
>
>o An anycast address must not be used as the source address of an
> IPv6 packet.
>
>
From: Joe Abley [mailto:[EMAIL PROTECTED]
> Correct. However, the v6 addressing spec prohibits the use of an
> anycast address from being used as the source address in a
> datagram, or
> being bound to an interface on a host. These two restrictions
> effectively prohibit the use of anycast as
On 6 Apr 2005, at 14:50, Fred Baker wrote:
Define "anycast address" in this question?
A single unicast address bound to multiple interfaces.
An IPv6 anycast address is indistinguishable from an IPv6 unicast
address. As such, any rule prohibiting the use of an anycast address
in any location is un
Define "anycast address" in this question?
An IPv6 anycast address is indistinguishable from an IPv6 unicast
address. As such, any rule prohibiting the use of an anycast address in
any location is unenforceable - I have no way to identify an anycast
address to apply the rule.
I didn't see th
52 matches
Mail list logo
