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

From: Bob Hinden <[email-masked]>
Date: Mon, 23 Mar 2009 14:36:37 -0700

Fred,

We have a design team in this area.  I suspect they were in the the  
v6ops session this morning.  I copied them here.

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?

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 14:52:08 -0700

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

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 24 Mar 2009 08:29:36 +0900

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:

> I'm pretty sure they were. I'm formally closing the loop here, which  
> I said I would do this morning.
>
>> Bob
>>
>>
>>> 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.
>>>
> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Mar 2009 00:08:06 +0000

> may be is utilized somewhere we don't know.

There is discussion of the current DT work in 6man on Tuesday - there
is certainly scope to discuss this there, to get input from the WG on
its perception of this issue.   There are certainly arguments to be
made either way.

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

Tim

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 24 Mar 2009 09:18:23 +0900

> in some way that an alternative path is not, for a specific  

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,

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 23 Mar 2009 19:14:21 -0400

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