crossbow discuss - Apr 2007 - IPv6 version specific classification in crossbow

Hi all,

As part of IPv6 version specific classification support in crossbow we are
introducing ip_version option in flowadm interface and associated 
classification functions.
If ip_version option is not specified, but v4 or v6 address is passed as 
arg. to ip_addr
option of flowadm cli that can also help to populate version specific 
bits in flow_mask
to specify if policy (and flow entry instance) is for IPv6 type flow or 
IPv4 type flow.

Here ,
lack of specification of ip_version and ip_addr options would result in 
ambiguity in
classification.

To be more specific:
consider, if user defines a flow policy as :
#flowadm add-flow -d bge0 transport=TCP local_port=8080 tcp1

To resolve this, we have following design choices and I need your 
opinion, to figure out
which one is the most adequate in above situation.

1)
We should internally create 2 flows(i.e. 2 flow_entry_t structures in 
flow table),
1 for ipv4 and other for ipv6

Pros: Administrator friendly, as  saves key-strokes.
Cons: Any flow would be either v4 type or v6 type.
          always creating 2 flows would result in waste of resources.
would add complexity in flow_table structure.

2)
We should interpret lack of specification of ip_version, to  be 
interpreted implicitly
as ipv4 only flow and for ipv6 type flows, ip_version should always be 
specified
and we should document this in a man page.

Pros  : Most of the flows are IPv4 based so such default behavior would 
cover broader
        category, correctly, while trying to save few key strokes.
Cons :  It does not follow dual-stack semantics and error-prone for IPv6 
flows.

3)
We should enforce use of ip_version option for each policy being 
defined  and
libflowadm  should error out on user, unless such a option specified.

Pros  : No ambiguity due to clear semantics.
Cons:  Requires administrator to specify ip_version for each and every 
policy to
          be defined.

4)
We should create single flow entry in flow table with a flow mask as  
transport as TCP
and port number as 8080 and classify both v4 and v6 packets with TCP as 
transport  and
8080 port number when matched to this flow entry in flow table.

Pros: This way we can keep the architecture simple.
Cons: It is ambiguous.

so based on above,
What should be the default behavior,  if  ip_version and/or ip_addr 
options are not
explicitly specified by user in the flowadm cli ?

Thanks in advance,
-Deepti

On Tue, 17 Apr 2007 13:40:31 -0700
deepti dhokte <Deepti.Dhokte at Sun.COM> wrote:

[...]
> 1)
> We should internally create 2 flows(i.e. 2 flow_entry_t structures in 
> flow table),
> 1 for ipv4 and other for ipv6
> 
> Pros: Administrator friendly, as  saves key-strokes.
> Cons: Any flow would be either v4 type or v6 type.
>           always creating 2 flows would result in waste of resources.
> would add complexity in flow_table structure.
This doesn''t waste resources if the user intended to create both.  In
addition these are pretty small control structures, right?  Its not
good to waste resources but its hard to get too excited.

How does it add complexity?
> 
> 2)
> We should interpret lack of specification of ip_version, to  be 
> interpreted implicitly
> as ipv4 only flow and for ipv6 type flows, ip_version should always be 
> specified
> and we should document this in a man page.
> 
> Pros  : Most of the flows are IPv4 based so such default behavior would 
> cover broader
The word "most" here worries me.  Basing an interface decision based
upon a dynamic aspect of usage like this seems inappropriate.
>         category, correctly, while trying to save few key strokes.
> Cons :  It does not follow dual-stack semantics and error-prone for IPv6 
> flows.
But it is likely to be true for a while and more importantly our other
tools work like that.  I''m not sure what you mean by "it does not
follow dual-stack semantics".
> 
> 3)
> We should enforce use of ip_version option for each policy being 
> defined  and
> libflowadm  should error out on user, unless such a option specified.
> 
> Pros  : No ambiguity due to clear semantics.
> Cons:  Requires administrator to specify ip_version for each and every 
> policy to
>           be defined.
This seems like a poor decision to me.  Mostly all downside.  The lack
of ambiguity upside is weakened by it being a suprise relative to other
tools.
> 
> 4)
> We should create single flow entry in flow table with a flow mask as  
> transport as TCP
> and port number as 8080 and classify both v4 and v6 packets with TCP as 
> transport  and
> 8080 port number when matched to this flow entry in flow table.
> 
> Pros: This way we can keep the architecture simple.
> Cons: It is ambiguous.
But you lose the ability to treat v4 and v6 differently, correct?  That
seems like a non starter for me.
> 
> so based on above,
> What should be the default behavior,  if  ip_version and/or ip_addr 
> options are not
> explicitly specified by user in the flowadm cli ?
I would go with #2.

	mph
> 
> Thanks in advance,
> -Deepti
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Thanks Michael for sharing your opinion. Please see inline.

Michael Hunter wrote:
> On Tue, 17 Apr 2007 13:40:31 -0700
> deepti dhokte <Deepti.Dhokte at Sun.COM> wrote:
>
> [...]
>   
>> 1)
>> We should internally create 2 flows(i.e. 2 flow_entry_t structures in 
>> flow table),
>> 1 for ipv4 and other for ipv6
>>
>> Pros: Administrator friendly, as  saves key-strokes.
>> Cons: Any flow would be either v4 type or v6 type.
>>           always creating 2 flows would result in waste of resources.
>> would add complexity in flow_table structure.
>>     
>
> This doesn''t waste resources if the user intended to create both. 
yeah. if not specifying ip_version is the conscious choice by user it 
would make sense to
have 2 flow entry and that should work.
if user does not specify such option by mistake and we assume s/he might 
be wanting both and
create 2 flow-entry, one would be always wasted and redundant structure, 
which will be
unused, due to wrong assumption.
>  In
> addition these are pretty small control structures, right?  
It can add up fast, If user created 50 such policies we would create 100 
structures.
> Its not
> good to waste resources but its hard to get too excited.
>
> How does it add complexity?
>   
as in above example, creating 50 v4 type and 50 v6 type flow entries for 
50 policies would require
to create 2 flow tables per interface/mac. one will be for v4 type and 
another will be for v6 type.
That makes it complex.
>   
>> 2)
>> We should interpret lack of specification of ip_version, to  be 
>> interpreted implicitly
>> as ipv4 only flow and for ipv6 type flows, ip_version should always be 
>> specified
>> and we should document this in a man page.
>>
>> Pros  : Most of the flows are IPv4 based so such default behavior would
>> cover broader
>>     
>
> The word "most" here worries me.  Basing an interface decision
based
> upon a dynamic aspect of usage like this seems inappropriate.
>   
yeah. that seem inappropriate. my point is IPv6 usage does not seem 
common place.
so on broader scope it is likely that we may deal more with v4 flows for 
some time,
but again, agreed,  that may not be the case forever.
>   
>>         category, correctly, while trying to save few key strokes.
>> Cons :  It does not follow dual-stack semantics and error-prone for
IPv6
>> flows.
>>     
>
> But it is likely to be true for a while
yeah, that''s what I meant above.
>  and more importantly our other
> tools work like that.  I''m not sure what you mean by "it does
not
> follow dual-stack semantics".
>
>   
what I intend is , a mere assumption that if not specifying ip_version 
should imply its a v4flow
works against dual-stack effort. so this is kinda
asymmetric.
>> 3)
>> We should enforce use of ip_version option for each policy being 
>> defined  and
>> libflowadm  should error out on user, unless such a option specified.
>>
>> Pros  : No ambiguity due to clear semantics.
>> Cons:  Requires administrator to specify ip_version for each and every 
>> policy to
>>           be defined.
>>     
>
> This seems like a poor decision to me.  Mostly all downside.  The lack
> of ambiguity upside is weakened by it being a suprise relative to other
> tools.
>
>   
>> 4)
>> We should create single flow entry in flow table with a flow mask as  
>> transport as TCP
>> and port number as 8080 and classify both v4 and v6 packets with TCP as
>> transport  and
>> 8080 port number when matched to this flow entry in flow table.
>>
>> Pros: This way we can keep the architecture simple.
>> Cons: It is ambiguous.
>>     
>
> But you lose the ability to treat v4 and v6 differently, correct?  That
> seems like a non starter for me.
>   
yes. that''s correct. :-(
>   
>> so based on above,
>> What should be the default behavior,  if  ip_version and/or ip_addr 
>> options are not
>> explicitly specified by user in the flowadm cli ?
>>     
>
> I would go with #2.
>   
-Deepti
> 	mph
>
>   
>> Thanks in advance,
>> -Deepti
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>     
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>