Upon review one thing occurred to me also - Netmasks are specifically a fast way to decide at the router which direction a packet should go. The interface netmask is part of the IP part of the header and allows the router to quickly determine whether a packet should go to the external rather than internal interface.
When you use the expression 'should x exist in todays internet', an unspoken aspect of this has to do with IPv6, which does not have a formal NAT specification, and 'local address' range that is as big as the whole IPv4 is now. This serves a similar purpose for routing as a netmask in IPv4, but IPv6 specifically aims to solve the problem of allowing inbound routing to any node. The address shortage that was resolved by CIDR and NAT is not relevant to IPv6, and I believe, in general, applications are written to generate valid addresses proactively and only change it in the rare case it randomly selects an address already in use. This is an optimistic algorithm that can save a lot of latency for a highly dynamic server application running on many worker node machines. Yes, it's long past due that we abandon IPv4 and NAT, peer to peer applications and dynamic cloud applications are becoming the dominant form for applications and the complexity of arranging peer to peer connections in this environment is quite high compared to IPv6. IPv6 does not need masks as they are built into the 128 bit address coding system. On Thursday, 2 May 2019 14:09:09 UTC+2, Louki Sumirniy wrote: > > 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.
