The function has a very specific purpose that I have encountered in several 
applications, that being to automatically set the netmask based on the IP 
being one of the several defined ones, 192, 10, and i forget which others. 

Incorrect netmask can result in not recognising a LAN address that is 
incorrect. A 192.168 network has 255 available addresses. You can't just 
presume to make a new 192.168.X... address with a /16, as no other 
correctly configured node in the LAN will be able to route to it due to it 
being a /16. 

If you consider the example of an elastic cloud type network environment, 
it is important that all nodes agree on netmask or they will become 
(partially) disconnected from each other. An app can be spun up for a few 
seconds and grab a new address from the range, this could be done with a 
broker (eg dhcp), but especially with cloud, one could use a /8 address 
range and randomly select out of the 16 million possible, a big enough 
space that random generally won't cause a collision - which is a cheaper 
allocation procedure than a list managing broker, and would be more suited 
to the dynamic cloud environment.

This function allows this type of client-side decisionmaking that a broker 
bottlenecks into a service, creating an extra startup latency cost. A 
randomly generated IP address takes far less time than sending a request to 
a centralised broker and receiving it.

That's just one example I can think of where a pre-made list of netmasks is 
useful, I'm sure more experienced network programmers can rattle off a 
laundry list.

On Monday, 11 March 2019 20:45:32 UTC+1, John Dreystadt wrote:
>
> Yes, I was mistaken on this point. I got confused over someone's 
> discussion of RFC 1918 with what the standard actually said. I should have 
> checked closer before I posted that point. But I still don't see the reason 
> for this function. In today's networking, the actual value you should use 
> for a mask on an interface on the public Internet is decided by a 
> combination of the address range you have and how it is divided by your 
> local networking people. On the private networks, it is entirely up to the 
> local networking people. The value returned by this function is only a 
> guess, and I think it is more likely to mislead than to inform.
>
> On Friday, March 8, 2019 at 12:51:41 PM UTC-5, Tristan Colgate wrote:
>>
>> Just on a point of clarity. DefaultMask is returning the mask associates 
>> with the network class. RFC1918 specifies a bunch of class A,B and C 
>> networks for private use. E.g. 192.168/16 is a set of 256 class C networks. 
>> The correct netmask for one of those class Cs is 255.255.255.0 (/24). So 
>> the function returns the correct thing by the RFC.
>>   
>>
>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to