Issues encountered with assigning .0 and .255 as usable addresses?
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. On Mon, Oct 22, 2012 at 4:07 PM, Paul Zugnoni <paul.zugnoni@jivesoftware.com> wrote:
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.
-- -------------------- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
On Mon, Oct 22, 2012 at 5:07 PM, Paul Zugnoni <paul.zugnoni@jivesoftware.com
wrote:
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.
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.
On 10/22/12 17:18 -0500, Matt Buford wrote:
On Mon, Oct 22, 2012 at 5:07 PM, Paul Zugnoni <paul.zugnoni@jivesoftware.com
wrote:
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.
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.
I had a similar experience about 10 years ago, with DSL customers who had been assigned .0 or .255 addresses not able to reach some sites. -- Dan White
Hi Paul, On Oct 22, 2012, at 5:07 PM, Paul Zugnoni <paul.zugnoni@jivesoftware.com> wrote:
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.
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! Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ So yes, apparently problems like these still arise once in a while. My recommendation would be to fix the equipment and not blame it on .0 or .255. Kind regards, Job Snijders
* Job Snijders
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!
Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/
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. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
I purposely assigned myself a .0 and never had a problem using anything online, or going anywhere
Date: Tue, 23 Oct 2012 22:00:53 +0200 From: tore.anderson@redpill-linpro.com To: job@instituut.net Subject: Re: Issues encountered with assigning .0 and .255 as usable addresses? CC: nanog@nanog.org
* Job Snijders
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!
Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/
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.
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
ok... so lets look at some space here. 98.32.0.0/22 98.32.0.0/32 is clearly on the unusable boundary. what about 98.32.0.255/32 & 98.32.1.0/32 ??? 98.32.4.255/32 is also clearly on the unusable boundary... UNTIL the delegation moves from a /22 to a /21. Then its usable. clear? thought so. /bill On Tue, Oct 23, 2012 at 10:00:53PM +0200, Tore Anderson wrote:
* Job Snijders
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!
Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/
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.
-- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
From: Paul Zugnoni [mailto:paul.zugnoni@jivesoftware.com]
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. David
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. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
In message <201210222307.q9MN7AIv063740@aurora.sol.net>, Joe Greco writes:
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.
Some of us park stuff on .0 and .255 addresses in order to motivate others to change.
... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CN N) With 24 million small businesses in the US alone, that's way too many apples.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On 10/22/12, Paul Zugnoni <paul.zugnoni@jivesoftware.com> wrote: [snip]
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 -- -JH
Hello, On Mon, Oct 22, 2012 at 10:07:50PM +0000, Paul Zugnoni wrote:
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. Is that sort of thing common? Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting
RFC 2526 reserves the last 128 host addresses in each subnet for anycast use. On Tue, Oct 23, 2012 at 7:15 AM, Andy Smith <andy@strugglers.net> wrote:
Hello,
On Mon, Oct 22, 2012 at 10:07:50PM +0000, Paul Zugnoni wrote:
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.
Is that sort of thing common?
Cheers, Andy
-- http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
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
Hi Rob, On Tue, Oct 23, 2012 at 08:16:48AM -0500, Rob Laidlaw wrote:
RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.
D'oh, I didn't even think to check for reserved addresses. Thanks. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting
On 23 October 2012 14:16, Rob Laidlaw <laidlaw@consecro.com> wrote:
RFC 2526 reserves the last 128 host addresses in each subnet for anycast use.
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. - Mike
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 Regards, Marc Storck
On Tue, Oct 23, 2012 at 9:18 AM, Mike Jones <mike@mikejones.in> wrote:
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.
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.
Hi,
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.
I discussed this with Hetzner and it seems to be a bug in JunOS 10.3R1.9. - Sander
participants (18)
-
Andy Smith -
bmanning＠vacation.karoshi.com -
Bryan Tong -
Dan White -
Darren O'Connor -
David Hubbard -
Jimmy Hess -
Job Snijders -
Joe Greco -
Joel Maslak -
Marc Storck -
Mark Andrews -
Matt Buford -
Mike Jones -
Paul Zugnoni -
Rob Laidlaw -
Sander Steffann -
Tore Anderson