Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255.
Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason.
As far as I know. There is no RFC based restrictions based on having
those as usable IPs.
We have been routing customers IP blocks on our network for a while
and never had a problem with 0 or .255 as the assigned IP even with
Microsoft Windows 2003 as the operating system.
Im not sure how to fix your issue but I dont think its automatically
disregarded by anyone that would seem silly.
Way back in the late 90's I tried this with a /23 dialup DHCP pool and
quickly found that the .0 and .255 users couldn't get to some scattered web
sites, though they seemed to be able to get to most of the Internet.
However, a year or so ago I spun up an always-on Amazon ec2 instance with a
static IP and was handed a .0 address. I still use this VM regularly and
have not run into any problems with reachability for this address.
Curious whether it's commonplace to find systems that
automatically regard .0 and .255 IP addresses (ipv4) as
src/dst in packets as traffic that should be considered
invalid. When you have a pool of assignable addresses, you
should expect to see x.x.x.0 and x.x.x.255 in passing traffic
(ie. VIP or NAT pool, or subnets larger than /24). Yet I've
run into a commercial IP mgmt product and getting reports of
M$ ISA proxy that is specifically blocking traffic for an IP
ending in .0 or .255.
Any experience or recommendations? Besides replace the ISA
proxy.... Since it's not mine to replace. Also curious whether
there's an RFC recommending against the use of .0 or .255
addresses for this reason.
We're a web host and over the past 12 years we've randomly
attempted to put non-critical customer sites on .0 and .255
addresses and found customers fairly consistently had
problems accessing them. These would typically be sites
for development, etc. where the customer was the only one
accessing it and even then it has been a high percentage
of failures. It is nearly always the customer's small biz
/ home office cheap-o router that is the issue even in this
day and age but occassionally it has been the ISP as well.
I haven't kept a list of vendors/isp's unfortunately so I
don't have more useful information to offer you other
than that it's still a problem. We still use those
addresses for that purpose since they'd otherwise go to
waste but most of the time it ends up being changed when
the customer tries to access it from somewhere and can't.
d be considered invalid. When you have a pool of assignable addresses, you =
should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or N=
AT pool, or subnets larger than /24). Yet I've run into a commercial IP mgm=
t product and getting reports of M$ ISA proxy that is specifically blocking=
traffic for an IP ending in .0 or .255.
To make a long story short:
If it's a product you're considering buying, problems with .0 and .255
reflect on the competence of the product's designers. You can safely
assume that there are many other Severely Broken Things too and move on
to saner products.
For general Internet use, there is a lot of gear out there that's ten or
more years old. You should avoid using .0 and .255 addresses if you can
avoid it, though it's a shame to waste valid IP space to accommodate the
brokenness of someone else's stuff.
Some of us park stuff on .0 and .255 addresses in order to motivate
others to change.
> d be considered invalid. When you have a pool of assignable addresses, you
> should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or N
> AT pool, or subnets larger than /24). Yet I've run into a commercial IP mgm
> t product and getting reports of M$ ISA proxy that is specifically blocking
> traffic for an IP ending in .0 or .255.
To make a long story short:
If it's a product you're considering buying, problems with .0 and .255
reflect on the competence of the product's designers. You can safely
assume that there are many other Severely Broken Things too and move on
to saner products.
For general Internet use, there is a lot of gear out there that's ten or
more years old. You should avoid using .0 and .255 addresses if you can
avoid it, though it's a shame to waste valid IP space to accommodate the
brokenness of someone else's stuff.
Ten year old equipment should be CIDR aware. It's not like it CIDR
wasn't in wide spread using in 2002.
Ten year old equipment should be CIDR aware. It's not like it CIDR
wasn't in wide spread using in 2002.
And BCP38 has had sufficient time to be globally deployed.
What's your point, again?
I was pretty careful in trying to outline that it's still expected
that there are defective products which even today will filter .0
and .255. This might be due to incompetence, or nobody having looked
at the code in a dozen years, or other various faults. There is no
central agency to validate gear against RFC, common use, and common
sense, and from what I hear, even Cisco has maintained "classful"
routing in useless contexts many years beyond what it should have.
The painful difference between "should be CIDR aware" (we agree on
this!) and "is actually CIDR compliant without amateur-hour mistakes"
is a measurable distance, even today.
Any experience or recommendations? Besides replace the ISA proxy…. Since
it's not mine to replace. Also curious whether there's an RFC recommending
against the use of .0 or .255 addresses for this reason.
ISA is old, and might not be supported anymore, unless you have an
extended support contract. If it's not supported anymore, then don't
be surprised if it has breakage you will not be able to repair. I
don't recommend upgrading to TMG, either: although still supported,
that was just discontinued.
If ISA is refusing traffic to/from IPs ending in .0, then ISA is
either broken, or misconfigured.
Get a support case with the vendor, raise it as a critical issue --
unable to pass traffic to critical infrastructure that ends with a
.255 or .0 IP address, demand that the vendor provide a resolution,
And explain that changing the IP address of the remote server is not an option.
If the vendor can't or won't provide a resolution, then not only is
the proxy server broken,
but malfunctioning in a way that has an impact on network connectivity.
I would consider its removal compulsory, as you never know, when a
network resource, web site, e-mail server, etc. your org has a
business critical need to access, or be accessed from; may be
placed on .255 or .0
Curious whether it's commonplace to find systems that
automatically regard .0 and .255 IP addresses (ipv4) as src/dst in
packets as traffic that should be considered invalid.
On a separate note, one of my customers discovered over the weekend
that if they bring up an all ones IPv6 address in their /64
(2001:db8:1:1:ffff:ffff:ffff:ffff) then they can't exchange traffic
with stuff hosted at hetzner.de such as archives.postgresql.org or 1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner.
I found the same if I brought up an all ones address in any other
/64 in the same /48 as well. Using ...ffff:ffff:ffff:fffe worked
fine.
I haven't had time to investigate further or tell them yet, though.
RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.
But that would mean that the ...:fffe address also shouldn't work. Considering RFC 2526 then filtering those addresses when used as source address makes sense.
- Sander
PS: I'm in contact with a network engineer from Hetzner now to see what is really happening
IPv4 addresses ending in .0 and .255 can't be used either because the
top and bottom addresses of a subnet are unusable.
Why would hetzner be making such assumptions about what is and is not
a valid address on a remote network? if you have a route to it then it
is a valid address that you should be able to exchange packets with,
any assumptions beyond that are almost certainly going to be wrong
somewhere.
Even if they did happen to correctly guess what sized subnets a remote
network is using and what type of access media that remote network is
using, I am pretty sure it would be wrong to assume that these
addresses can't be accessed remotely considering the only address that
is currently defined
I really hope this is down to some kind of bug and not something
someone did deliberately.
IPv4 addresses ending in .0 and .255 can't be used either because the
top and bottom addresses of a subnet are unusable.
Only true if speaking of /24, but with the appearance of CIDR 19 years
ago, this is not true anymore The .255 and .0 in the "center" of a /23
are perfectly usable see an earlier post http://markmail.org/message/n2ctx6tw6kdcj2mr
In the post-classfull routing world .0 and .255 should be normal IP
addresses. CIDR was only recently defined (somewhere in 1993) so I
understand it might take companies some time to adjust to this novel
situation. Ok, enough snarkyness!
AIUI, that particular problem couldn't be blamed on lack of CIDR support
either, as 91.218.150.255 is (was) a class A address. It would have had
to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful
pre-CIDR world.
That said, it's rather common for people to believe that a /24 anywhere
in the IPv4 address space is a �class C� so I'm not really surprised.
As to why: I suspect they don't know either. I wouldn't be surprised
if it was someone's misguided attempt years ago to stop smurf
amplification attacks, long since forgotten. I'm not saying it's a
good idea (it's not), just why I suspect someone would do this.
