PSARC/2008/250 IPv6 NAT for IPFilter

[yifan evan xu - Sun Microsystems - Beijing China]

I am sending the updated spec with respect to Gary's issue.

Yifan

Gary Winiger wrote:
> Evan writes:
>   
>> Gary Winiger wrote:
>>     
>>>> IPv6 NAT for IP Filter
>>>>
>>>> Overview
>>>> ========
>>>> This change request aims to provide IPv6 NAT capabilities for IP Filter.
>>>> The requested release binding is micro/patch.
>>>>     
>>>>         
>>>   
>>>       
>>>> Customer impact
>>>> ===============
>>>> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT 
>>>> sessions in kernel needs to rebuild their program due to the changes of
>>>> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h.
>>>>     
>>>>         
>>> 	What is the taxonomy of these ioctls.  If it is above Volatile,
>>> 	how is the incompatible change mitagated for the requested
>>> 	release binding?
>>>
>>>   
>>>       
>> It's "External Stable". Does it mean for functionality extension we need to
>> provide new ioctl? Are the header files changable? Or we need to provide new
>> header files? Can we add new structures into the old header files as long as
>> we guarantee that no recompiling action is required for original customers?
>>     
>
> 	I'm not sure what "External Stable" is, so I'll take it as the
> 	former Stable which is the current Committed.  And I'll ask again:
> 	"How is the incompatible change mitagated for the requested Patch
> 	release binding?"
>
> Darren write:
>   
>> There are a few things going on here...
>> 1) management isn't interested in investing in a non-ioctl API
>>    unless there is significant interest outside of engineering
>>    (there is some interest), meaning that internal changes that
>>    get reflected in changes to the ioctls either cost engineers
>>    a whole bunch of extra work or cause customers a bunch of
>>    pain/work;
>>
>> 2) the changes to support ipv6 NAT, in the external code base
>>    are being made as part of the next major release (4.x -> 5.x)
>>    but we're not doing that here...
>>
>> Feel free to accost said mangler when he returns O:-)
>>     
>
> 	I'm not sure what the reasons are, or if they really matter
> 	unless the architecture is wrong and then I'd leave that up
> 	to the Case Owner and the Case Submitter to work out before
> 	submitting the Fast Track.
>
> 	I'm asking the naive question presuming the Case Owner has approved
> 	of the general architecture and that's less up for discussion.
> 	If ioctls are the wrong architecture, the Case Owner should just
> 	derail or withdraw the case.
>
> Gary..
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipv6nat.txt
URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080418/d124ed90/attachment.txt>