Subject: Question about RFC 3484

From: François-Xavier Le Bail <[email-masked]>
Date: Mon, 26 Sep 2011 08:30:35 -0700 (PDT)

Hi All,

Section 4 of RFC 3484 states:
    (http://tools.ietf.org/html/rfc3484#section-4)
    4. Candidate Source Addresses
    [. . .]
       In any case, anycast addresses, multicast addresses, and the
       unspecified address MUST NOT be included in a candidate set.

Are a reply to an UDP datagram or ICMPv6 (e.g. ping) concerned ? 

If yes, what is the rationale for not including an anycast address ?

Thanks,
Francois-Xavier Le Bail

---

From: Tomoyuki Sahara <[email-masked]>
Date: Wed, 28 Sep 2011 09:28:50 +0900

Hi,

>        unspecified address MUST NOT be included in a candidate set.

I don't know the exact reason but RFC2373[1] says:

  2.6 Anycast Addresses
   ...
   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 agreed upon for those problems, the
   following restrictions are imposed on IPv6 anycast addresses:

      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.

(Note: statement above was removed in RFC4291)

Thanks,
Tomoyuki Sahara

---

From: François-Xavier Le Bail <[email-masked]>
Date: Wed, 28 Sep 2011 01:42:48 -0700 (PDT)

--- On Tue, 9/27/11, Tomoyuki Sahara <[email-masked]> wrote:

> From: Tomoyuki Sahara <[email-masked]>
> Subject: Re: Question about RFC 3484
> To: "François-Xavier Le Bail" <[email-masked]>
> Cc: [email-masked]
> Date: Tuesday, September 27, 2011, 8:28 PM
> Hi,
> 

Hi,

RFC 4291, appendix B states:
Appendix B: Changes from RFC 3513
   The following changes were made from RFC 3513, "IP Version 6
   Addressing Architecture":
    o The restrictions on using IPv6 anycast addresses were removed
      because there is now sufficient experience with the use of anycast
      addresses, the issues are not specific to IPv6, and the GROW
      working group is working in this area.

In this draft, we have a rationale for the remove of restictions regarding anycast as source address :
(http://tools.ietf.org/html/draft-jabley-v6-anycast-clarify-00#section-3.1)
"3.1 Anycast Source Addresses
   For many conventional services to be distributed using anycast, it is
   necessary for reply datagrams sent from servers to clients to be
   sourced from the same address that was used as the destination in
   request datagrams sent from clients to servers.  When such a service
   is distributed using anycast, the destination address used in request
   datagrams is necessarily an anycast address; corresponding reply
   packets must therefore use the same anycast address as their source
   address.
   Being able to use an anycast address as the source address in an IPv6
   datagram is a prerequisite for the distribution of many services
   using anycast over IPv6."

So, if the RFC 3484, Section 4 "Candidate Source Addresses" is involved in
the reply to datagrams sent to an anycast address, it might be useful to
reassess the restrictions that excluded an anycast address from the "candidate set", at least for the replies.

François-Xavier Le Bail

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Sep 2011 19:59:54 +0200

Francois,

> If yes, what is the rationale for not including an anycast address ?

because in the general case unaware applications do not work with anycast.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Sep 2011 09:44:21 +1300

On 2011-09-28 21:42, François-Xavier Le Bail wrote:
...
> reassess the restrictions that excluded an anycast address from the "candidate set", at least for the replies.

You would need to start a thread proposing a specific change to
draft-ietf-6man-rfc3484-revise if you want this to be done.

I'm not convinced; as Ole said, anycast remains a special case
for certain applications, so it will be hard to define a safe
general rule.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Sep 2011 11:13:01 +1000

In message <[email-masked]>, Brian E Carpenter writes:
> > reassess the restrictions that excluded an anycast address from the 
> "candidate set", at least for the replies.
> 

Just for reference, in the last week, there was a compliant in
bind-users that we were rejecting replies to queries sent to the
all routers IPv6 anycast address because the source address of the
reply did not match the destination address of the query.  The
anycast address can be used as source address relatively safely,
even for TCP, if you constrain the packets to be fragmented at
network MTU and to also include a fragment header in case they are
going through a IPv4/IPv6 translator.  With anycast you don't want
to trigger PMTU discovery.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Sep 2011 14:54:08 +1300

> to trigger PMTU discovery.

There's a similar issue in RFC3068 (anycast 6to4), which is
described in RFC6343, so I will not give details here.

    Brian