On Wed, 6 Apr 2005, The IESG wrote:
>
> The IESG has received a request from the IP Version 6 Working Group WG to
> consider the following document:
>
> - 'IP Version 6 Addressing Architecture'
> as a Draft Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> fi
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
All,
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 anycast address must
Hi,
I would like to propose that the restriction on the use of anycast for
host-based services be lifted in conjunction with the revision to the
v6 addressing specification. Specifically, that the following text in
section 2.6 be removed:
There is little experience with widespread, arbitrary
The IESG has received a request from the IP Version 6 Working Group WG to
consider the following document:
- 'IP Version 6 Addressing Architecture'
as a Draft Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any commen
Can someone explain the rational for why RFC 4007 mandates the scope
zone index before the prefix in the textual representation?
It appears to be the reverse of what I would expect. A prefix is
assocaited with the IP address itself (in6_addr), while the scope zone
index is associated with the
24 matches
Mail list logo
