In writing my response for the forum item, I've arrived at a couple of possible thesis topics, including
- IPv4 addressing considered limiting for CORBA application networks
- MAC addresses not considered sufficient for network device authentication
My response was as follows. For convenience, I'm just going to cut and paste my own response to the forum item, here.
As an obvious "Note to self," here shared in a sense, I think that it would behoove me to continue to study the IPv6 implementation on Linux.
As an obvious "Note to self," here shared in a sense, I think that it would behoove me to continue to study the IPv6 implementation on Linux.
Separately, there's the matter of MAC filtering, MAC spoofing, and alternately VPN architectures.
Ed note: Blogger's HTML editor has "Some issues" in regards to how it applies Cascading Stylesheets. I've had to process this HTML by hand, so that it will be legible to the reader. Of course, I used Emacs, for the quick markup change, in this item
Functionally, a subnet mask is a bitmask for the sequence of consecutive bits of an IPv4 address, with "all ones" for the bits that represent thenetwork address portion of the IPv4 address [ TCP/IP Guide Reference 1 , Reference 2 ]
Whether in CIDR addressing or classful addressing, subnetting revolves, functionally, around the application of a subnet mask.
In classful addressing, for address classes A through C, the classful IPv4 address' subnet masks is calculated at, each, a full byte boundary in the IPv4 address. [ TCP/IP Guide, Reference 3] Class A addressees have a subnet mask of 8 bits (one byte) in length, class B subnet masks are 16 bits in length, and class C address, 24 bits in length, with the remaining bits being avaialble for host addressing and subnetting on a single network.
In CIDR, a subnet mask may be defined at any any effective bit length less than 32 [TCP/IP Guide Reference 2].
For example, on a network using CIDR addressing, when the assigned IPv4 netmask for the network is 28 bits in length, 4 bits are then available for addresses for hosts and subnet gateways, on the network. That equates to 2^4 total addresses, namely 16.
If one may introduce a sidebar with regards to network address translation, as in an interest of informing the discussion with regards to IPv4 addressing:
Individual subnets of a network, if using network address translation, may use any of the IPv4 address ranges reserved for private IPv4 networks [ RFC1918 ] for addresses on any single, local subnet. In a network architecture using network address translation, the number of available host addresses, across all subnets -- rather, the number of "client" host addresses would be effectively infinite, i.e not a number
Network address translation introduces a corresponding concern, as with regards to availability of network services on a subnet M, for such servcies as must be available to hosts on any subnet not being a subnet of M. That may be addressed, effectively, with port fin orwarding at the network gateway and/or firewall on subnet M, wherein each individual network service that must be available on "Not M" must be assigned to a single port "P" on the network gateway for the "M" network itself. The packet filtering framework on M must then configured to forward packets delivered to port "P" of the network gateway, to forward those packets specifically any single port P' (P prime, may or may not be equal to P) on a host A on subnet M, such that host would be providing the required network service, on port "P prime". Of course, the packet filtering framework must also be configured correspondingly for network address translation, such that packets sent from A, in response to packets sent to A:P will be appropriately forwarded back to the requesting network peer, on its corresponding client socket port.
Candidly, on a further sidebar: A CORBA application architecture might not scale as well on an IPv4 network using network address translation, not as well as on an IPv6 network not using network address translation. (Considering that I've an interest in developing CORBA network services for consumer applications, and clearly this matter of IP address availability would pertain to CORBA service implementation, then I hope that it may be an apropos topic to continue about, briefly, here). In short, if a CORBA ORB on a network not M must access a CORBA ORB on a network M, and the gateway for M is using network address translation, then the number of ORBs that the ORB on not M may connect to is effectively limited to the number of available network ports on the network gateway for M. Moreover, in this situation, the configuration for network port forwarding on M may be decisively non-trivial. So, for a network of CORBA services, IPv6 network addressing would be preferred.
Continuing on that example, the network gateway for subnet M may be implemented with a Linux host, in which instance, Linux kernel netfiltermodules and the iptables command may be used for configuring the effective port forwarding schema for a subnet [ NAT HOWTO for Linux 2.4 and later kernel versions]. Citing personal experience, a Linux host with at least two network interfaces would be sufficient -- one network interface, dedicated to the "upstream" network, and the second network interface, connected to a switch on the Local Area Network or LAN.
Personally, I've not had any direct experience with server rack configurations. It's my assumption that there may be "Rack units" available for using Linux as a network gateway and firewall provider. I'm familiar with Linux networking, not really familiar with Windows NT networking. Though Linux might seem to have a more "Bare bones" user interface, primarily at the shell commands used for configuring such as a netfilter system, but I think it's easier to understand the expected results of configuration changes, using Linux shell commands, rather than some GUIs, candidly.
Of course, firewall configuration would be a tangential topic, overall. I'm at least familiar with so much of Linux firewall configuration as may be applied for network address translation.
Tangentially, a network firewall on a network gateway may also be applied for MAC-based peer filtering -- essentially, as to block unauthorized PCs from transmitting packets to services on the firewall, and to block unauthorized PCs from transmitting packets through the firewall -- in a sort of rudimentary "authorized network interfaces" configuration, such that can be implemented with bare-bones shell scripting, in Linux, or with further GUI configuration in a broader application design. Of course, it is possible to "spoof" a MAC address. So, I write "authorized network interfaces," rather than "Authorized devices," as it is possible, though it would not be ideal, for a single MAC address to be assigned to two or more network interfaces, possibly each on two or more separate network devices. Certainly, there are broader network security frameworks available for network peer authorization -- as may be applied within a single network architecture -- including X.509 certificates such as used in a VPN framework such as strongSwan
Whether in CIDR addressing or classful addressing, subnetting revolves, functionally, around the application of a subnet mask.
In classful addressing, for address classes A through C, the classful IPv4 address' subnet masks is calculated at, each, a full byte boundary in the IPv4 address. [ TCP/IP Guide, Reference 3] Class A addressees have a subnet mask of 8 bits (one byte) in length, class B subnet masks are 16 bits in length, and class C address, 24 bits in length, with the remaining bits being avaialble for host addressing and subnetting on a single network.
In CIDR, a subnet mask may be defined at any any effective bit length less than 32 [TCP/IP Guide Reference 2].
For example, on a network using CIDR addressing, when the assigned IPv4 netmask for the network is 28 bits in length, 4 bits are then available for addresses for hosts and subnet gateways, on the network. That equates to 2^4 total addresses, namely 16.
If one may introduce a sidebar with regards to network address translation, as in an interest of informing the discussion with regards to IPv4 addressing:
Individual subnets of a network, if using network address translation, may use any of the IPv4 address ranges reserved for private IPv4 networks [ RFC1918 ] for addresses on any single, local subnet. In a network architecture using network address translation, the number of available host addresses, across all subnets -- rather, the number of "client" host addresses would be effectively infinite, i.e not a number
Network address translation introduces a corresponding concern, as with regards to availability of network services on a subnet M, for such servcies as must be available to hosts on any subnet not being a subnet of M. That may be addressed, effectively, with port fin orwarding at the network gateway and/or firewall on subnet M, wherein each individual network service that must be available on "Not M" must be assigned to a single port "P" on the network gateway for the "M" network itself. The packet filtering framework on M must then configured to forward packets delivered to port "P" of the network gateway, to forward those packets specifically any single port P' (P prime, may or may not be equal to P) on a host A on subnet M, such that host would be providing the required network service, on port "P prime". Of course, the packet filtering framework must also be configured correspondingly for network address translation, such that packets sent from A, in response to packets sent to A:P will be appropriately forwarded back to the requesting network peer, on its corresponding client socket port.
Candidly, on a further sidebar: A CORBA application architecture might not scale as well on an IPv4 network using network address translation, not as well as on an IPv6 network not using network address translation. (Considering that I've an interest in developing CORBA network services for consumer applications, and clearly this matter of IP address availability would pertain to CORBA service implementation, then I hope that it may be an apropos topic to continue about, briefly, here). In short, if a CORBA ORB on a network not M must access a CORBA ORB on a network M, and the gateway for M is using network address translation, then the number of ORBs that the ORB on not M may connect to is effectively limited to the number of available network ports on the network gateway for M. Moreover, in this situation, the configuration for network port forwarding on M may be decisively non-trivial. So, for a network of CORBA services, IPv6 network addressing would be preferred.
Continuing on that example, the network gateway for subnet M may be implemented with a Linux host, in which instance, Linux kernel netfiltermodules and the iptables command may be used for configuring the effective port forwarding schema for a subnet [ NAT HOWTO for Linux 2.4 and later kernel versions]. Citing personal experience, a Linux host with at least two network interfaces would be sufficient -- one network interface, dedicated to the "upstream" network, and the second network interface, connected to a switch on the Local Area Network or LAN.
Personally, I've not had any direct experience with server rack configurations. It's my assumption that there may be "Rack units" available for using Linux as a network gateway and firewall provider. I'm familiar with Linux networking, not really familiar with Windows NT networking. Though Linux might seem to have a more "Bare bones" user interface, primarily at the shell commands used for configuring such as a netfilter system, but I think it's easier to understand the expected results of configuration changes, using Linux shell commands, rather than some GUIs, candidly.
Of course, firewall configuration would be a tangential topic, overall. I'm at least familiar with so much of Linux firewall configuration as may be applied for network address translation.
Tangentially, a network firewall on a network gateway may also be applied for MAC-based peer filtering -- essentially, as to block unauthorized PCs from transmitting packets to services on the firewall, and to block unauthorized PCs from transmitting packets through the firewall -- in a sort of rudimentary "authorized network interfaces" configuration, such that can be implemented with bare-bones shell scripting, in Linux, or with further GUI configuration in a broader application design. Of course, it is possible to "spoof" a MAC address. So, I write "authorized network interfaces," rather than "Authorized devices," as it is possible, though it would not be ideal, for a single MAC address to be assigned to two or more network interfaces, possibly each on two or more separate network devices. Certainly, there are broader network security frameworks available for network peer authorization -- as may be applied within a single network architecture -- including X.509 certificates such as used in a VPN framework such as strongSwan
No comments:
Post a Comment