Re: [addr-select-dt] RFC 3484 issues in address selection in the presence of an IPv4 NAT

[Suresh Krishnan <[e-mail]>]

Hi Folks,
  The point I wanted to make in v6ops was that it is difficult to come 
up with any kind of priorities for selection between IPv4,private IPv4, 
Transitional IPv6 and native IPv6 addresses that will fit all deployment 
scenarios. So a dynamic policy would be the way to go.

Thanks
Suresh

Arifumi Matsumoto wrote:
> Fred and Robert,
> thank you for shepherding.
>
> Today's session made me feel that changing the existing *default* 
> address selection behavior is too difficult, now that that behavior 
> may be is utilized somewhere we don't know.
>
> So, we definitely need customization mechanism of address selection 
> policy in application-specific, host-specific, and site-specific way.
>
> Best,
>
> On 2009/03/24, at 6:52, Fred Baker wrote:
>
>>
>> On Mar 23, 2009, at 2:36 PM, Bob Hinden wrote:
>>
>>> Fred,
>>>
>>> We have a design team in this area.  I suspect they were in the the 
>>> v6ops session this morning.  I copied them here.
>>
>> I'm pretty sure they were. I'm formally closing the loop here, which 
>> I said I would do this morning.
>>
>>> Bob
>>>
>>>
>>> On Mar 23, 2009, at 2:02 PM, ext Fred Baker wrote:
>>>
>>>> I'd like to bring
>>>>
>>>> http://tools.ietf.org/html/draft-denis-v6ops-nat-addrsel
>>>> "Problems with IPv6 source address selection and IPv4 NATs", Remi
>>>> Denis-Courmont, 18-Feb-09, <draft-denis-v6ops-nat-addrsel-00.txt>
>>>>
>>>> to your attention. We discussed it briefly this morning in v6ops. 
>>>> The sense of the room was that it was likely related to your effort 
>>>> to improve RFC 3484.
>>>>
>>>> Along those lines, the discussion at the mike included at least two 
>>>> points that RFC 3484 runs afoul of. One is that RFC 3484 enables no 
>>>> API for administrative control, and administrators are likely to 
>>>> want to update it in their environments. The other is that the 
>>>> logic that addresses have degrees of likelihood of being useful in 
>>>> a fixed order - any fixed order - is problematic. Rather, one might 
>>>> have an initial order one uses, but as the system gains experience 
>>>> of what address selections are most useful, it would be better to 
>>>> have the OS, guided by the application, try those addresses that 
>>>> have historically been useful first.
>>>>
>>>> How would you recommend proceeding? Would you prefer to take this 
>>>> draft into 6man and including it in the RFC 3484 update?
>>>
>>
>> _______________________________________________
>> addr-select-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>
> _______________________________________________
> addr-select-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/addr-select-dt