On Feb 22, 2012, at 6:19 PM, Dave Thaler wrote: > 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.
Works for me. Bob > > -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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
