Going back through all these old threads while I'm working on rfc3484bis...

If anycast addresses are no longer prohibited in general, I don't see why
we should call out any in particular.  If an implementation wants to include
them or exclude them, it's up to the implementation.

Previously RFC 3484 said anycast MUST NOT be included in the candidate
source addresses set.   It did not contain any MUSTs about what *is* included.
It has a RECOMMENDED statement, and statements about what not to include.

So once the MUST NOT is removed, it's already implementation specific and
becomes a quality-of-implementation issue.   If someone has a way to
make some anycast address work, then it's fine to include as a source address.

-Dave

> -----Original Message-----
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> François-Xavier Le Bail
> Sent: Thursday, November 10, 2011 5:59 AM
> To: Arifumi Matsumoto
> Cc: ipv6@ietf.org
> Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt
> 
> ----- Original Message -----
> 
> > From: Arifumi Matsumoto <a...@arifumi.net>
> > To: François-Xavier Le Bail <fx.leb...@yahoo.com>
> > Cc: "ipv6@ietf.org" <ipv6@ietf.org>
> > Sent: Wednesday, November 9, 2011 12:56 AM
> > Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt
> >
> > Hi,
> >
> > Thanks for your suggestion.
> >
> > , and also we should also mention about Reserved IPv6 Subnet Anycast
> Addresses ?
> > http://tools.ietf.org/html/rfc2526
> 
> Hi,
> 
> I had a look at RFC 2526.
> 
> It's seems it's the same case than SRaa, but I have no practical experience 
> with
> such a reserved subnet anycast address.
> 
> has someone an experience with these ?
> 
> François-Xavier
> 
> >
> > 2011/11/7 François-Xavier Le Bail <fx.leb...@yahoo.com>:
> >>
> >>  Hi,
> >>
> >>  The draft has taken into account anycast addresses.
> >>
> >> http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05#section-
> >> 2.6
> >>
> >>  It remains to handle the special case of Subnet-Router anycast address.
> >>  (http://tools.ietf.org/html/rfc4291#section-2.6.1)
> >>  "The Subnet-Router anycast address is intended to be used for
> >> applications where a node needs to communicate with any one of the
> >> set of routers."
> >>
> >>  So, I think a SRaa must be excluded from the candidate set of source
> > address
> >>  for a new communication.
> >>  The SRaa as source address must be reserved for a reply to a packet
> >> sent to
> > this SRaa.
> >>
> >>  Text proposal (to add section 2.6) :
> >>  "As an exception, a Subnet-Router anycast address MUST NOT be
> >> included
> > in the
> >>  candidate set of source address when initiating communication.
> >>  The Subnet-Router anycast address as source address MUST be used in
> >> a  reply to a packet sent to this Subnet-Router anycast address".
> >>
> >>  Thanks,
> >>  François-Xavier
> >>
> >>
> >>  ----- Original Message -----
> >>>  From: "internet-dra...@ietf.org"
> > <internet-dra...@ietf.org>
> >>>  To: i-d-annou...@ietf.org
> >>>  Cc: ipv6@ietf.org
> >>>  Sent: Tuesday, November 1, 2011 12:52 AM
> >>>  Subject: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt
> >>>
> >>>  A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >>>  This draft is a work item of the IPv6 Maintenance Working Group of
> >>> the
> > IETF.
> >>>
> >>>      Title           : Update to RFC 3484 Default Address Selection
> >>> for
> > IPv6
> >>>      Author(s)       : Arifumi Matsumoto
> >>>                            Jun-ya Kato
> >>>                            Tomohiro Fujisaki
> >>>                            Tim Chown
> >>>      Filename        : draft-ietf-6man-rfc3484-revise-05.txt
> >>>      Pages           : 12
> >>>      Date            : 2011-10-31
> >>>
> >>>     RFC 3484 describes algorithms for source address selection and
> >>> for
> >>>     destination address selection.  The algorithms specify default
> >>>     behavior for all Internet Protocol version 6 (IPv6) implementations.
> >>>     This document specifies a set of updates that modify the
> >>> algorithms
> >>>     and fix the known defects.
> >>>
> >>>
> >>>  A URL for this Internet-Draft is:
> >>>
> > http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05.
> > txt
> >>>
> >>>  Internet-Drafts are also available by anonymous FTP at:
> >>>  ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>>  This Internet-Draft can be retrieved at:
> >>>
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05.t
> > xt
> >>>
> >>> --------------------------------------------------------------------
> >>>  IETF IPv6 working group mailing list  ipv6@ietf.org  Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>
> >>> --------------------------------------------------------------------
> >>>
> >>  --------------------------------------------------------------------
> >>  IETF IPv6 working group mailing list  ipv6@ietf.org  Administrative
> >> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>  --------------------------------------------------------------------
> >>
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to