Subject: Changes to MLD to support Anycast

From: Brian Haberman <[email-masked]>
Date: Thu, 09 May 2002 12:18:46 -0400

All,
     Just to give everyone the ability to review the draft, here is
the announcement of the draft outlining changes to MLD to support
hosts announcing their membership in anycast groups.  Ideally, these
changes will get incorporated into the MLDv2 spec at some point.

Regards,
Brian

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : Host-based Anycast using MLD
>         Author(s)       : B. Haberman, D. Thaler
>         Filename        : draft-haberman-ipngwg-host-anycast-01.txt
>         Pages           : 5
>         Date            : 08-May-02
> 
> This specification defines extended uses of the Multicast Listener
> Discovery protocol to support hosts participating in anycast groups.
> The extensions presented in this document allow hosts to notify the
> routing system of membership changes in an anycast group.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-host-anycast-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-haberman-ipngwg-host-anycast-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-haberman-ipngwg-host-anycast-01.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 10 May 2002 01:35:06 +0900

>changes will get incorporated into the MLDv2 spec at some point.

	i believe we don't have consensus on how we should deal with anycast
	route injection.  there are at least several ways.  my preference is
	with the first option below.  as anycast address is being be treated
	in similar ways as unicast address, i think it most natural option.

itojun

- node with anycast address(*) participating routing exchange
	pros: deployable now, routing protocol has mechanisms for
		protecting against malicious route injection (sometimes
		they are just "use IPsec"...)
	cons: some hates it when the node is a host
- node with anycast address(*) sending MLD packet, adjacent router injects
  a route to the cloud
	pros: less entity speaking routing protocol
	cons: deployment delay, protection mechanism not really there

(*) must be a router based on RFC2460

---

From: [email-masked]
Date: Fri, 10 May 2002 01:38:34 +0900

>	in similar ways as unicast address, i think it most natural option.

	it also is consistent with currently-practiced IPv4 anycast (or,
	unicast address assigned to multiple nodes), like those documented in
	draft-ietf-dnsop-*-shared-root-server*.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Thu, 09 May 2002 13:47:09 -0400

My concern with the first option is that it requires new functionality
on the host joining an anycast group, namely running a routing protocol.
Generally, hosts already support MLD/IGMP in order to join multicast
groups, so why require them to run a routing protocol?

Brian

---

From: [email-masked]
Date: Fri, 10 May 2002 12:56:47 +0900

>on the host joining an anycast group, namely running a routing protocol.

	it is not new at all.  hosts have been running routing protocol daemons
	for a long time (sometimes it was only listening, like "routed -q").

>groups, so why require them to run a routing protocol?

	at this moment no client implementation issues MLD join for
	anycast address, so it is a large change to make.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Sun, 12 May 2002 14:46:00 -0400

>         anycast address, so it is a large change to make.

Sure, that is to be expected.  The primary change would have to be in
the checking of the group address.  Today, implementations check to
ensure that the group address passed in the join is a multicast
address.  So this is a change to the stack implementation.  In order
to perform authentication, MLD would have to be protected with a
security scheme similar to that used for routing protocols.

Your proposal would not require changes to a stack.  The operator
would be required to run whatever intra-domain routing protocol,
possibly with some security key to protect the infrastructure, so
the server would become a part of the set of trusted boxes in the
network.

I prefer having a fewer number of boxes injecting routes, but I am
not committed to either approach yet.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 May 2002 10:21:30 -0400

>         cons: some hates it when the node is a host

And how does a host, on the same link with the anycast-capable node,
know to find that node locally?  Do we have to accept triangular
routing from host to router to anycast-capable node?

Brian

---

From: [email-masked]
Date: Mon, 13 May 2002 23:42:01 +0900

>routing from host to router to anycast-capable node?

	if the /64 prefix for the anycast address is the same as one used on
	the subnet, normal ND works just fine.  otherwise, icmp6 redirect will
	take care of it.  so there's no issue.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 May 2002 10:41:06 -0400

>         take care of it.  so there's no issue.

Ugh, my brain was locked.  Too early to be posting. :)

Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 21 May 2002 16:24:19 +0300 (EEST)

Hello,

A few comments.

As stated before by others, this seems like a hack.  But sometimes hacks 
can be good.  Anyway..

==> The big picture: this deals with the situation where anycast members 
are on the same link (and/or possibly even different links attached to the 
same upstream router).

This is probably the most difficult part of host anycast, but one should 
also consider how one would turn these anycast MLD reports to something 
usable in the routing system.  This is IMO important as anycast/multicast 
is very different in this sense (joining the multicast distribution tree 
vs advertising one address).

==> Based on MLD, there may be implementations that check that the address 
in MLD message is a multicast address and discard (probable)/send error on 
such packets.

==> I think everyone agrees that security considerations is a bit of 
handwaving :-)

  4.2  Receiving Report Messages
    
   When a router receives an MLD Report message, an anycast Report
   message is distinguished from a multicast Report message by the MLD
   Multicast Address field.  An anycast group address can be managed in
   the same manner as a multicast group address.  All of the timers and
   state machines defined in RFC 2710 also apply to anycast group 
   management. 

==> the router must keep track of the nodes reporting to a group, so that 
packets to that anycast address can be delivered to it.  Or does the 
router use normal neighbour discovery and just record on which links there 
may be potential anycast members for an address?

  4.3  Receiving Leave Messages
    
      [...] The reception of an anycast Leave message must trigger
   the transmission of an Address-Specific Query for the specified
   anycast address.

==> This and some others may be more or less useless, as MLD for
multicast/anycast is different (which has only been implied in the draft,
AFAIR): the router must keep the addresses of nodes acting as (potential) 
anycast group members anyway (which is not necessary for multicast).

   The receiving router must verify that:
    
           -  The IPv6 Source Address is a link-local address
           -  The MLD checksum field is valid 

==> In MLD, it is checked that the message is at least 24 bytes long too?

It seems to me that something like "Binding Updates" are a more natural 
approach to host anycast membership problem (not counting using normal 
routing system in a host).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian Haberman <[email-masked]>
Date: Tue, 21 May 2002 10:13:03 -0400

Pekka,

> As stated before by others, this seems like a hack.  But sometimes hacks

The original concept was based on the premise that group membership is
similar in multicast and anycast.  The hosts that are a member of a
group need to report that fact to the routers.

> vs advertising one address).

The routing issues are very important, but they are out of scope of
reporting group membership information to the routers.  The routing
aspects should be covered in a separate draft.

> in MLD message is a multicast address and discard (probable)/send error on

Yes.  And the MLD spec will need to be modified to remove that kind
of check.

> ==> I think everyone agrees that security considerations is a bit of

Group security in general needs more work.  I am currently looking at
draft-irtf-gsec-sgmv6-00.txt for help in that area.

> may be potential anycast members for an address?

Either method could be used.  But given all the information that the
router's group database needs to support for IGMPv3/MLDv2 anyway, it
should be reasonable to keep a list of anycast members.

> anycast group members anyway (which is not necessary for multicast).

See response to the last comment.

> ==> In MLD, it is checked that the message is at least 24 bytes long too?

Yep.  That is covered in section 5 of RFC 2710.

> routing system in a host).

That is another possibility that has been mentioned on the list.  If
you look at the problem abstractly, Mobile IP is a close fit.  The
anycast address is the "home address" and the unicast addresses of the
anycast group members are a set of "care-of addresses".  Of course,
if the care-of address changes, so does the machine you are talking to.

Brian