Subject: Re: Question about RFC 3484

From: François-Xavier Le Bail <[email-masked]>
Date: Mon, 3 Oct 2011 02:00:38 -0700 (PDT)

Ole,

> > 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 ?
> 
> because in the general case unaware applications do not
> work with anycast.

RFC 3484 states:
"It is desirable to have default algorithms, common across all 
implementations, for selecting source and destination addresses
so that developers and administrators can reason about and
predict the behavior of their systems."

So the algorithms must take into account the anycast addresses in replies.

Thanks,
François-Xavier

---

From: François-Xavier Le Bail <[email-masked]>
Date: Mon, 3 Oct 2011 02:32:55 -0700 (PDT)

Brian

> > 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.
> 
> 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.

I would agree, but the goal of the RFC 3484 is to "predict the behavior
of the systems" and we see that actual behaviour on routers with SRAA is
implementations dependant, because the RFC 4291 allows a reply with an
anycast address as source and the RFC 3484 forbids it.

Thanks,
François-Xavier

Thanks,
François-Xavier

---

From: François-Xavier Le Bail <[email-masked]>
Date: Mon, 3 Oct 2011 05:37:46 -0700 (PDT)

Mark,

> Brian E Carpenter writes:
> > On 2011-09-28 21:42, François-Xavier Le Bail wrote:
> > > 
> > > 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.
> > 
> > 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
>
> 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

Thanks, another argument for a reply with an anycast address is given in
RFC 4942:
2.1.6. Anycast Traffic Identification and Security
[. . .]
   To avoid exposing knowledge about the internal structure of the
   network, it is recommended that anycast servers now take advantage of
   the ability to return responses with the anycast address as the
   source address if possible.

François-Xavier