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.sumirniy.stal...@gmail.com> > 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 golang-nuts+unsubscr...@googlegroups.com. > 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.
