I'm quite aware of that, it's part of the ARP, and allows the router to quickly determine which port to send to. If you put say 192.168.1.1 to a router configured with DHCP to 192.168.0.x/24 it first checks the mask by ANDing it with the list of address/port network lists' gateway to find the port that matches (mask removes the part with the arbitrary addressable range), it will return no path error packet to the machine that sent it.
responding back to John Dreystadt - Since netmasks are about ARP address resolution and routing and not DHCP or BIND, they most definitely do belong there in the "net" library. Firstly, yes, you could just change it to a set of constants, but why?? Secondly, if you aren't gonna bake the non-routeable address ranges default netmasks into the network library, then where? The use case is easy for me to see: dynamic cloud service providers need to generate virtual IP addresses for virtual lans in a cluster. Sure you could force the dev/admin to input the netmask for every request to use when generating new addresses for virtual interfaces, but why? I might even go from the opposite direction here: what about a function that gives you a address range/netmask based on the number of addresses you want? Isn't that also the same, and also necessary for dynamic VLAN management. On Thursday, 2 May 2019 14:38:04 UTC+2, Robert Engels wrote: > > The net mask is not part of the ip packet. It is a local config in the > router. > > On May 2, 2019, at 7:20 AM, Louki Sumirniy <louki.sumi...@gmail.com > <javascript:>> wrote: > > 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 golan...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- 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.
