On 14/11/2012 07:48, Sean Chittenden wrote:
Regardless, why are you trying to do something that is unsupported by pretty
much every vendor/operator/os?
Status quo is fine and dandy if it's rational, backed up with a justification
and can be understood, but I'm not seeing anything that suggests there's a good
reason which indicates 0/8 shouldn't be used or supported. -sc
It's official registration is for "self identification", "this" network doesn't
mean the connected network.
All in all, even allowing an address in 0/8 to be configured is a bug based on
both a) the various RFCs and intended use and b) that's how everyone else
accepts that it should work anyway, so RFC is irrelevant in that case.
I think that's incorrect. 127/8 is used for hosts local to a physical server and 0/8 was intended for hosts
"local to a network." In my definition, "this network" is data center-local, however
there's nothing preventing that IP address range from being rack-local either, etc. 0.0.0.0/32 is a shortcut
for saying "me on this network," which makes sense in the context of the wording in RFC 5735.
Again, section 3 paragraph 1:
0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network ([RFC1122], Section 3.2.1.3).
In environments where DNS is an extra service that requires justification and
would be an additional service that has to be secured, exclusive use of well
known IP addresses is both convenient and useful, and the 0/8 network seems to
have been defined for exactly this purpose. I admit the address range isn't in
wide use atm, but I don't see a reason for it to not be.
The fix Andre made appears to be correct, and IMO, should be merged in to -head
and MFC'ed.
http://www.secnetix.de/~olli/FreeBSD/svnews/index.py?r=242956
Cheers (& thank you Andre for making the commit). -sc
--
Sean Chittenden
s...@chittenden.org
It is quite clearly for self identification, major vendors and other
reference OSes, eg Linux/Windows don't allow it, thus this is *wrong*.
What we now have is a stack that's even more non-rfc/best practice
compliant because *you* couldn't pick a sensible address like everyone else.
There are 10 distinct ranges to choose from that whilst not being
advisable, are not special cases and thus are valid.
Andre,
There are plenty of reserved ranges that *are* valid and *are* usable by
other vendors/systems.
Based on the rfc wording and vendor documents saying it should be a
source address only and everyone else treating it as a special range (as
it should be, like 224/4) and others such as link local, this should be
reverted.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
