Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt

[Bob Hinden <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> François-Xavier Le Bail
>> Sent: Thursday, November 10, 2011 5:59 AM
>> To: Arifumi Matsumoto
>> Cc: [e-mail]
>> Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt
>> 
>> ----- Original Message -----
>> 
>>> From: Arifumi Matsumoto <[e-mail]>
>>> To: François-Xavier Le Bail <[e-mail]>
>>> Cc: "[e-mail]" <[e-mail]>
>>> 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 <[e-mail]>:
>>>> 
>>>> 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: "[e-mail]"
>>> <[e-mail]>
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]
>>>>> 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  [e-mail]  Administrative
>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list  [e-mail]  Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> 
>>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------