[157471] in North American Network Operators' Group
Re: Issues encountered with assigning .0 and .255 as usable addresses?
daemon@ATHENA.MIT.EDU (james machado)
Tue Oct 23 13:39:32 2012
In-Reply-To: <1350957003920-019-01412098.jkrejci.usinternet.com@192.168.1.61>
Date: Tue, 23 Oct 2012 10:39:08 -0700
From: james machado <hvgeekwtrvl@gmail.com>
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mon, Oct 22, 2012 at 6:49 PM, Justin Krejci <jkrejci@usinternet.com> wro=
te:
> And since owen has not yet mentioned it, consider something that supports=
having : in its address as well.
>
> Sort of tangentially related, I had a support rep for a vendor once tell =
me that a 255 in the second or third octet was not valid for an ipv4 addres=
s. Hard to troubleshoot a problem when I had to first explain how ip addres=
sing worked because the rep was so fixated on the 255 we were using on the =
network. If any product really doesn't like 255 in any position then you sh=
ould consider yourself lucky to still be in business at all. Jimmy Hess <my=
sidia@gmail.com> wrote:On 10/22/12, Paul Zugnoni <paul.zugnoni@jivesoftware=
.com> wrote:
> [snip]
>> Any experience or recommendations? Besides replace the ISA proxy=85. Sin=
ce
>> it's not mine to replace. Also curious whether there's an RFC recommendi=
ng
>> 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 o=
ption.
>
>
> 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
>
this was also discussed back in August in this thread
http://mailman.nanog.org/pipermail/nanog/2012-August/051290.html
james
