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

[Tim Chown <[e-mail]>]

On Tue, Mar 24, 2009 at 08:29:36AM +0900, 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.

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.

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

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