Subject: RE: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

From: [email-masked]
Date: Thu, 7 Apr 2005 09:01:56 +0300

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 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.
> 
> to
> 
>     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.
> 
> I would like people to chime in before April 15, 2005 with their opinion on
> making this change.

I support this change. Based on the discussions, I think that there seems to
be well thought-out uses for using an anycast address as a source address,
and similar uses of anycast in IPv4.  

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Apr 2005 23:50:52 -0700

proposed text...

Replace

with

  - An anycast address is used for very short exchanges, such as single 
packet each way (DNS) or rendezvous exchanges (IPsec/IKE/ISAKMP). Use 
of Anycast as a source address in longer exchanges runs the risk of 
routing changing in the network and the stated shared by the 
communicating end stations being lost. For longer exchanges with an 
anycast service, a protocol must be defined that communicates to the 
originator of the session a stable address of the system it is 
communicating with, to be used for the substance of the exchange.

  - An anycast address is never advertised to the network by a host in 
neighbor discovery, but rather by a router or host advertising itself 
as a reasonable router to that end station. If routing fails, fail-over 
to another interface serving the address is this automatic.

---

From: Rob Austein <[email-masked]>
Date: Thu, 07 Apr 2005 03:23:11 -0400

> 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 architecture doc imposes on use of anycast in IPv6.  The
rest of the issues are IP-version-independent, and are already under
consideration in another WG which has the relevant routing expertise.
So I think the best thing for the IPv6 WG per se to do would be to
clear up the old IPv6-specific restrictions, then bow out gracefully.

If folks from the IPv6 WG want to wander over to GROW and chat about
the issues Fred's proposed text attempts to document, that sounds like
a fine and useful thing, and I'm sure that the folks over in GROW
would be happy to get additional eyes reviewing their work, but to me
that looks like a separate activity in a separate WG and does not need
to be tightly coupled to the IPv6 address architecture doc.

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Apr 2005 11:38:16 -0400

On 7 Apr 2005, at 03:23, Rob Austein wrote:

> prefer Brian's original proposal.

To further paraphrase Rob's comments here, there is a lot to think 
about when considering the deployment of services using anycast; to 
insert comprehensive text on that subject into the draft at hand would 
require a lot more than two paragraphs.

The issues that Fred addressed with his text are discussed at length in 
draft-ietf-grow-anycast. I would submit that the grow document is the 
right place for them, and that it's not necessary to duplicate them in 
the v6 addressing architecture: in fact, I think clarity is best served 
by keeping them separate.

Joe

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Apr 2005 09:09:45 -0700

Sounds eminently logical. I think it makes sense to remove the restriction
in draft-ietf-ipv6-addr-arch but spend some time discussing the finer points
in more depth rather than try to craft some text on the fly to substitute.
GROW might be the right place to do so (I see there's a draft about anycast
there) but I do note that the GROW charter does not specifically mention
anycast, and some of the issues discussed in this thread may involve more
IGP rather than EGP operations, which seems to be GROW's focus.

            jak

----- Original Message ----- 
From: "Rob Austein" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>; "IPv6 WG"
<[email-masked]>
Sent: Thursday, April 07, 2005 12:23 AM
Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Apr 2005 09:23:46 -0700

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?

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Apr 2005 12:55:44 -0400

> 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-arch-v4-02 be simply removed from section 2.6:

>>    There is little experience with widespread, arbitrary use of 
>> Internet
>>    anycast addresses, and some known complications and hazards when
>>    using them in their full generality [ANYCST].  Until more 
>> experience
>>    has been gained and solutions are specified, the following
>>    restrictions are imposed on IPv6 anycast addresses:
>>

Brian's note, which quotes draft-jabley-v6-anycast-clarify-00, is below.

Joe

> On Apr 6, 2005, at 10:22 AM, Brian Haberman wrote:
>
>> All,
>> It should be noted that the addressing architecture is currently in 
>> IETF Last
>> Call.

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Apr 2005 10:36:54 -0700

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.