inconsistent address treatment.

inconsistent address treatment.

[Stephen Clark]

Hello,

Why the inconsistency in the way addresses are treated. I can use -d 
2.2.2.2/32
  but not --to-source 205.201.149.214/32

iptables -t nat -A POSTROUTING -o eth1 -s 10.0.128.0/17 -d 2.2.2.2/32 -j 
SNAT --to-source 205.201.149.214/32


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: inconsistent address treatment.

[Pascal Hambourg]

Hello,

Stephen Clark a écrit :
> 
> Why the inconsistency in the way addresses are treated. I can use -d 
> 2.2.2.2/32
>   but not --to-source 205.201.149.214/32

Because -d takes a prefix and --to-source takes an address range.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Jan Engelhardt]

On Thursday 2010-12-23 15:12, Stephen Clark wrote:

> Hello,
>
> Why the inconsistency in the way addresses are treated. I can use -d 2.2.2.2/32
> but not --to-source 205.201.149.214/32
>
> iptables -t nat -A POSTROUTING -o eth1 -s 10.0.128.0/17 -d 2.2.2.2/32 -j SNAT
> --to-source 205.201.149.214/32

What inconsistency?

Re: inconsistent address treatment.

[Stephen Clark]

On 12/23/2010 04:53 PM, Jan Engelhardt wrote:
> On Thursday 2010-12-23 15:12, Stephen Clark wrote:
>
>    
>> Hello,
>>
>> Why the inconsistency in the way addresses are treated. I can use -d 2.2.2.2/32
>> but not --to-source 205.201.149.214/32
>>
>> iptables -t nat -A POSTROUTING -o eth1 -s 10.0.128.0/17 -d 2.2.2.2/32 -j SNAT
>> --to-source 205.201.149.214/32
>>      
> What inconsistency?
>    
If you try the above command you get a complaint about

--to-source 205.201.149.214/32
you have to use
--to-source 205.201.149.214

iptables 1.4.5.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>    


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: inconsistent address treatment.

[Stephen Clark]

On 12/23/2010 02:52 PM, Pascal Hambourg wrote:
> Hello,
>
> Stephen Clark a écrit :
>    
>> Why the inconsistency in the way addresses are treated. I can use -d
>> 2.2.2.2/32
>>    but not --to-source 205.201.149.214/32
>>      
> Because -d takes a prefix and --to-source takes an address range.
>    

So? you can't parse

205.201.149.214/32-205.201.149.218/32


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Pascal Hambourg]

Stephen Clark a écrit :
> On 12/23/2010 02:52 PM, Pascal Hambourg wrote:
>>
>> Stephen Clark a écrit :
>>    
>>> Why the inconsistency in the way addresses are treated. I can use -d
>>> 2.2.2.2/32
>>>    but not --to-source 205.201.149.214/32
>>>      
>> Because -d takes a prefix and --to-source takes an address range.
> 
> So? you can't parse
> 
> 205.201.149.214/32-205.201.149.218/32

a.b.c.d/32 is a prefix notation, even though it represents a single
address. IMO it does not make sense to use a prefix notation in an
interval, so I don't see why the parser should handle it. AFAICS, other
commands such as 'ip' from iproute don't accept /32 prefixes where a
single address is expected either.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Jan Engelhardt]

On Thursday 2010-12-23 23:43, Stephen Clark wrote:
> On 12/23/2010 04:53 PM, Jan Engelhardt wrote:
>> On Thursday 2010-12-23 15:12, Stephen Clark wrote:
>>
>>> Why the inconsistency in the way addresses are treated. I can use -d
>>> 2.2.2.2/32
>>> but not --to-source 205.201.149.214/32
>>>
>>> iptables -t nat -A POSTROUTING -o eth1 -s 10.0.128.0/17 -d 2.2.2.2/32 -j SNAT
>>> --to-source 205.201.149.214/32
>>>     
>> What inconsistency?
>>   
> If you try the above command you get a complaint about
>
> --to-source 205.201.149.214/32
> you have to use
> --to-source 205.201.149.214

Ah "that" sort of "inconsensitency". No, that is not an inconsistency.
-d takes an addr[/mask] or a addr[/prefixlen] or a list thereof, while
-m iprange and DNAT's --to-source take addr[-addr].

Each is subtly different. And documented.

Re: inconsistent address treatment.

[Stephen Clark]

On 12/24/2010 03:20 AM, Pascal Hambourg wrote:
> Stephen Clark a écrit :
>    
>> On 12/23/2010 02:52 PM, Pascal Hambourg wrote:
>>      
>>> Stephen Clark a écrit :
>>>
>>>        
>>>> Why the inconsistency in the way addresses are treated. I can use -d
>>>> 2.2.2.2/32
>>>>     but not --to-source 205.201.149.214/32
>>>>
>>>>          
>>> Because -d takes a prefix and --to-source takes an address range.
>>>        
>> So? you can't parse
>>
>> 205.201.149.214/32-205.201.149.218/32
>>      
> a.b.c.d/32 is a prefix notation, even though it represents a single
> address. IMO it does not make sense to use a prefix notation in an
> interval, so I don't see why the parser should handle it. AFAICS, other
> commands such as 'ip' from iproute don't accept /32 prefixes where a
> single address is expected either.
>    
Well It is just one more idiosyncrasy one has to remember, when to me there
is no obvious reason for it to be so. It also means if you are writing 
some kind
of automated tool to create rules for iptables from a set of address objects
then you have remember, Oh I have to drop the /32 if this object is used
as an argument for --to-source. That means everyone that trys to develop
an automated tool has to deal with this anomaly instead of  being dealt with
in one place, the parser for iptables.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Stephen Clark]

On 12/24/2010 03:46 AM, Jan Engelhardt wrote:
> On Thursday 2010-12-23 23:43, Stephen Clark wrote:
>    
>> On 12/23/2010 04:53 PM, Jan Engelhardt wrote:
>>      
>>> On Thursday 2010-12-23 15:12, Stephen Clark wrote:
>>>
>>>        
>>>> Why the inconsistency in the way addresses are treated. I can use -d
>>>> 2.2.2.2/32
>>>> but not --to-source 205.201.149.214/32
>>>>
>>>> iptables -t nat -A POSTROUTING -o eth1 -s 10.0.128.0/17 -d 2.2.2.2/32 -j SNAT
>>>> --to-source 205.201.149.214/32
>>>>
>>>>          
>>> What inconsistency?
>>>
>>>        
>> If you try the above command you get a complaint about
>>
>> --to-source 205.201.149.214/32
>> you have to use
>> --to-source 205.201.149.214
>>      
> Ah "that" sort of "inconsensitency". No, that is not an inconsistency.
> -d takes an addr[/mask] or a addr[/prefixlen] or a list thereof, while
> -m iprange and DNAT's --to-source take addr[-addr].
>
> Each is subtly different. And documented.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>    
Just because it is documented doesn't mean it is not inconsistent.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: inconsistent address treatment.

[Jan Engelhardt]

On Friday 2010-12-24 16:32, Stephen Clark wrote:
>>>> Because -d takes a prefix and --to-source takes an address range.
>>>
>>>So? you can't parse
>>>205.201.149.214/32-205.201.149.218/32
>>
>>a.b.c.d/32 is a prefix notation, even though it represents a single
>>address. IMO it does not make sense to use a prefix notation in an
>>interval, so I don't see why the parser should handle it. AFAICS, other
>>commands such as 'ip' from iproute don't accept /32 prefixes where a
>>single address is expected either.
>
>Well It is just one more idiosyncrasy one has to remember, when to me there
>is no obvious reason

Historical reasons.

Possible extra explanations:

- DNAT was added later than the -s argument, and someone thought
  it's better to use a range, since a range can be more expressive
  than addr[/prefixlen] for the same memory usage.
- On the other hand, since iptables also accepts addr[/mask], and it
  also allows /masks that are not representable as a /prefixlen, it
  is not necessarily specifying a contiguous range which may be
  useless to use with DNAT to some.

Re: inconsistent address treatment.

[Amos Jeffries]

On 25/12/10 10:48, Jan Engelhardt wrote:
>
> On Friday 2010-12-24 16:32, Stephen Clark wrote:
>>>>> Because -d takes a prefix and --to-source takes an address range.
>>>>
>>>> So? you can't parse
>>>> 205.201.149.214/32-205.201.149.218/32
>>>
>>> a.b.c.d/32 is a prefix notation, even though it represents a single
>>> address. IMO it does not make sense to use a prefix notation in an
>>> interval, so I don't see why the parser should handle it. AFAICS, other
>>> commands such as 'ip' from iproute don't accept /32 prefixes where a
>>> single address is expected either.
>>
>> Well It is just one more idiosyncrasy one has to remember, when to me there
>> is no obvious reason
>
> Historical reasons.
>
> Possible extra explanations:
>
> - DNAT was added later than the -s argument, and someone thought
>    it's better to use a range, since a range can be more expressive
>    than addr[/prefixlen] for the same memory usage.
> - On the other hand, since iptables also accepts addr[/mask], and it
>    also allows /masks that are not representable as a /prefixlen, it
>    is not necessarily specifying a contiguous range which may be
>    useless to use with DNAT to some.

FWIW: we (Squid project) use the syntax "ip[-ip][/mask]". This is simple 
enough to parse and is a bit more flexible.

/2c

AYJ

Re: inconsistent address treatment.

[Jan Engelhardt]

On Sunday 2010-12-26 13:10, Amos Jeffries wrote:

> On 25/12/10 10:48, Jan Engelhardt wrote:
>>
>> On Friday 2010-12-24 16:32, Stephen Clark wrote:
>>>>>> Because -d takes a prefix and --to-source takes an address range.
>>>>>
>>>>> So? you can't parse
>>>>> 205.201.149.214/32-205.201.149.218/32
>>>>
>>>> a.b.c.d/32 is a prefix notation, even though it represents a single
>>>> address. IMO it does not make sense to use a prefix notation in an
>>>> interval, so I don't see why the parser should handle it. AFAICS, other
>>>> commands such as 'ip' from iproute don't accept /32 prefixes where a
>>>> single address is expected either.
>>>
>>> Well It is just one more idiosyncrasy one has to remember, when to me there
>>> is no obvious reason
>>
>> Historical reasons.
>>
>> Possible extra explanations:
>>
>> - DNAT was added later than the -s argument, and someone thought
>>   it's better to use a range, since a range can be more expressive
>>   than addr[/prefixlen] for the same memory usage.
>> - On the other hand, since iptables also accepts addr[/mask], and it
>>   also allows /masks that are not representable as a /prefixlen, it
>>   is not necessarily specifying a contiguous range which may be
>>   useless to use with DNAT to some.
>
> FWIW: we (Squid project) use the syntax "ip[-ip][/mask]". This is simple enough
> to parse and is a bit more flexible.

Indeed, but we don't have the space for it ;-)
There are just two uint32s available in the current struct ipt_ip,
so it's either ip-ip or ip/mask.
Of course, in the near future, the ipv4 match can be extended just like 
other extensions (revision bump).

Re: inconsistent address treatment.

[Stephen Clark]

On 12/26/2010 07:47 AM, Jan Engelhardt wrote:
> On Sunday 2010-12-26 13:10, Amos Jeffries wrote:
>
>    
>> On 25/12/10 10:48, Jan Engelhardt wrote:
>>      
>>> On Friday 2010-12-24 16:32, Stephen Clark wrote:
>>>        
>>>>>>> Because -d takes a prefix and --to-source takes an address range.
>>>>>>>                
>>>>>> So? you can't parse
>>>>>> 205.201.149.214/32-205.201.149.218/32
>>>>>>              
>>>>> a.b.c.d/32 is a prefix notation, even though it represents a single
>>>>> address. IMO it does not make sense to use a prefix notation in an
>>>>> interval, so I don't see why the parser should handle it. AFAICS, other
>>>>> commands such as 'ip' from iproute don't accept /32 prefixes where a
>>>>> single address is expected either.
>>>>>            
>>>> Well It is just one more idiosyncrasy one has to remember, when to me there
>>>> is no obvious reason
>>>>          
>>> Historical reasons.
>>>
>>> Possible extra explanations:
>>>
>>> - DNAT was added later than the -s argument, and someone thought
>>>    it's better to use a range, since a range can be more expressive
>>>    than addr[/prefixlen] for the same memory usage.
>>> - On the other hand, since iptables also accepts addr[/mask], and it
>>>    also allows /masks that are not representable as a /prefixlen, it
>>>    is not necessarily specifying a contiguous range which may be
>>>    useless to use with DNAT to some.
>>>        
>> FWIW: we (Squid project) use the syntax "ip[-ip][/mask]". This is simple enough
>> to parse and is a bit more flexible.
>>      
> Indeed, but we don't have the space for it ;-)
> There are just two uint32s available in the current struct ipt_ip,
> so it's either ip-ip or ip/mask.
> Of course, in the near future, the ipv4 match can be extended just like
> other extensions (revision bump).
>
>    
That is a reasonable answer.


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: inconsistent address treatment.

[Pascal Hambourg]

Amos Jeffries a écrit :
> 
> FWIW: we (Squid project) use the syntax "ip[-ip][/mask]".

I'm being curious : what is the meaning of "ip-ip/mask" when both the
range and mask are present ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Jan Engelhardt]

On Sunday 2010-12-26 22:43, Pascal Hambourg wrote:

>Amos Jeffries a écrit :
>> 
>> FWIW: we (Squid project) use the syntax "ip[-ip][/mask]".
>
>I'm being curious : what is the meaning of "ip-ip/mask" when both the
>range and mask are present ?

Sounds like

192.168.0.64-192.168.191/255.255.255.253
<=>
192.168.0.{64 65 68 69 72 73 76 77 77...}

Well, it's probably of use... to someone.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Amos Jeffries]

On 27/12/10 11:16, Jan Engelhardt wrote:
> On Sunday 2010-12-26 22:43, Pascal Hambourg wrote:
>
>> Amos Jeffries a écrit :
>>>
>>> FWIW: we (Squid project) use the syntax "ip[-ip][/mask]".
>>
>> I'm being curious : what is the meaning of "ip-ip/mask" when both the
>> range and mask are present ?
>
> Sounds like
>
> 192.168.0.64-192.168.191/255.255.255.253
> <=>
> 192.168.0.{64 65 68 69 72 73 76 77 77...}
>
> Well, it's probably of use... to someone.

For yourselves I was thinking limit it to CIDR masks.
As in:
  192.168.0.0/24               ==> 19.168.0.0-192.168.0.255
  192.168.1.0-192.168.10.0/23  ==> 192.168.1.0-192.168.11.255
  192.168.0.0-192.168.100.0/24 ==> 192.168.0.0-192.168.100.255

Netmasks get a bit tricky and as you say you don't have enough storage 
space to hold the mask as well.

AYJ
Ps. sorry for the slow reply, holidays.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inconsistent address treatment.

[Jan Engelhardt]

On Saturday 2011-01-08 05:20, Amos Jeffries wrote:
>>>>
>>>> FWIW: we (Squid project) use the syntax "ip[-ip][/mask]".
>>>
>>> I'm being curious : what is the meaning of "ip-ip/mask" when both the
>>> range and mask are present ?
>>
>> Sounds like
>>
The scheme (a-b)/msk:
>>
>> 192.168.0.64-192.168.191/255.255.255.253
>> <=>
>> 192.168.0.{64 65 68 69 72 73 76 77 77...}
>>
>> Well, it's probably of use... to someone.
Squid's a-lastof(b/plen):
> For yourselves I was thinking limit it to CIDR masks.
> As in:
> 192.168.1.0-192.168.10.0/23  ==> 192.168.1.0-192.168.11.255

If, for any combination of a,b,plen in your a-lastof(b/plen), you get a
contiuguous range [and that does seem to be the case], it is
redundant to store plen, since that can just be expressed by an
appropriate contiguous range a-c.

That said, a-b/plen does look confusing, because one might
also assume (a-b)/plen:

192.168.1.0-192.168.10.0/23 => 192.168.0.0-192.168.11.255
(Because 192.168.1.0/23's top is 192.168.0.0)