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

[Arifumi Matsumoto <[e-mail]>]

>> So, we definitely need customization mechanism of address selection
>> policy in application-specific, host-specific, and site-specific way.
>
> The application-specific issues are certainly interesting - as we  
> discussed
> this morning you may hit other 'middlebox' issues than the NAT issue  
> that
> this draft discusses, e.g. a 'better' path may be firewalled or  
> filtered
> in some way that an alternative path is not, for a specific  
> application
> protocol/port.

As you know it, addr-select-api already provides this mechanism to  
some extent.
NAT kind of manipulation should be done by application developer,  
though.

Best,

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