Subject: [Mip6] Call for Participation on IPv6 Anycast discussion ML

From: Hiroshi KITAMURA <[email-masked]>
Date: Wed, 27 Oct 2004 10:53:03 +0900

Dear All,

People, who are interested in IPv6 Anycast discussion, please read
this mail.

I thing there are many people who are interested in IPv6 Anycast.
Since IPv6 Anycast has many good potential functionalities, many
people are expecting that it will be widely used in the real-world.

Currently, IPv6 Anycast is only used at limited area for limited
purpose. It is a pity that IPv6 Anycast is not widely used.
This situation should be changed.

A small IPv6 Anycast discussion team has been made by people who are
interested in this topic.

http://anycast.anarg.jp/
	is a web site for IPv6 Anycast discussion.
[email-masked] 
	is a ML for it.

People, who are interested in IPv6 Anycast discussion, please join this
ML and let us know your comments. Let's discuss on IPv6 Anycast issues 
at this ML.
(Instruction how to join the ML is written in above web site.)

We have already issued four I-Ds on IPv6 Anycast.
(Of course, they are under construction.)

1. IPv6 Anycast Terminology Definition
2. Applicability Statement of IPv6 Anycasting
3. A Protocol for Anycast Address Resolving
4. Possible Deployment Scenarios for IPv6 Anycasting

You can find them at above web site.

We'd like to have a Practical Anycasting BoF in the near future. 
We have already talked with Internet Area Directors on this issue.
A draft for charter proposal is written in above web site, 
please read them and let us know your comments.

Regards,
Hiroshi

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 27 Oct 2004 11:14:02 +0900 (JST)

(sorry to spam 3 wgs, i have not received response to subscription
	request for [email-masked] yet)

> draft-ata-ipv6-anycast-resolving-02.txt
> A Protocol for Anycast Address Resolving

	due to the way the proposal resolves (or hides) anycast address
	into unicast address, we will experience a severe problem.  application
	thinks that it is communicating with anycast address AA, but ARL
	(basically a NAT within client) translates it into unicast address.

	therefore, applications which embeds address into its protocol payload
	(like ftp) won't work as expected. section 4 (applicability statement)
	is not true.

	appendix A (how to map anycast address into unicast) basically has no
	security considerations.  section 5 (security consideration) is also
	too weak.

	another issue with this approach is, that anycast is being used as
	service discovery mechnaism on the first contact only.  anycast has
	other benefits such as failure recovery/tolerance.  these benefits are
	gone with this draft.

itojun