ICTNWK311 Install and test network protocols

A protocol is a set of rules that says how two devices will communicate: what a message looks like, in what order messages are exchanged, how errors are handled, and how each side knows the other has understood. Human conversation runs on protocols too; we take turns, we say "sorry, what?" when a word is missed, and we open with a greeting and close with a goodbye. A network protocol is the same idea written down precisely enough that two machines built by different vendors, running different software, can talk without ambiguity.

The unit asks a question that sounds odd until you see the point of it: why are protocols not affected by the size or complexity of a network? Because a protocol is a rule, and the rule does not care how many devices follow it. The Transmission Control Protocol behaves the same way between two laptops in a home office as it does between two data centres carrying millions of connections. A larger network needs more addresses, more equipment and more careful design, but the protocols running across it are unchanged. This is why the same handful of protocols underpins both a three-device home setup and the global internet, and it is why learning the protocols well is worth the effort: the knowledge scales without changing.

Networking is layered, and there are two models for describing the layers. Both split communication into levels, each with its own job, so that a change at one level does not force a change at the others; the physical cabling can change without touching the web browser, and the web browser can change without touching the cabling.

The TCP/IP model, also called the internet protocol suite, is the one the internet actually runs on. It has four layers. The application layer is where user-facing protocols live, such as those for web, email and file transfer. The transport layer moves data between programs and decides whether delivery is guaranteed; this is where TCP and UDP sit. The internet layer moves packets between networks and is where IP and addressing live. The network access layer, sometimes split into data link and physical, handles the local delivery over the actual medium, such as Ethernet or Wi-Fi. The suite carries many protocols, but as its name says, the two that define it are TCP and IP.

The OSI model is a seven-layer reference model used mainly for teaching and troubleshooting. It provides a common language and a standard way to describe communication without tying the description to any one technology. Its layers, from the top, are application, presentation, session, transport, network, data link and physical. Nobody builds networks strictly to the OSI model, but everybody uses its vocabulary; when an engineer says a problem is "layer 1", meaning a cable or a port, or "layer 7", meaning the application, they are speaking OSI. Knowing how the two models line up is a core skill, and it is stable knowledge that has not dated.

flowchart LR
  subgraph OSI[OSI model, seven layers]
    O7[7 Application]
    O6[6 Presentation]
    O5[5 Session]
    O4[4 Transport]
    O3[3 Network]
    O2[2 Data link]
    O1[1 Physical]
  end
  subgraph TCPIP[TCP/IP model, four layers]
    T4[Application]
    T3[Transport]
    T2[Internet]
    T1[Network access]
  end
  O7 --- T4
  O6 --- T4
  O5 --- T4
  O4 --- T3
  O3 --- T2
  O2 --- T1
  O1 --- T1

Before a single protocol is installed, the network is designed, and design starts with requirements rather than equipment. The questions the delivered material lists are the right ones: will the network be centrally administered or peer to peer; what devices and services must run on it; how many devices need access, and to which parts; how much traffic is expected at peak; what addressing structure fits; and how the business is organised into departments. The answers shape everything downstream, such as how many subnets are needed, how addresses are allocated per department or device group, and whether the network follows the classic core, distribution and access structure.

Scale changes the design without changing the protocols. A small office or home office might run flat, with one subnet, a single router and a handful of devices, and get its addresses automatically. A large organisation segments the network into many subnets by department or function, plans its addressing carefully, and builds in layers so traffic and faults stay contained. Understanding the vendor's product range matters here too, because the equipment chosen shapes what the design can do; a vendor that does not make a full range of intermediary devices may force a mixed-vendor network or a change of vendor, and a product due for release soon may be worth waiting for if it brings a real improvement for little extra cost.

Every device on a network needs an address, and there are two versions of the Internet Protocol in use. IPv4 uses 32-bit addresses, written as four numbers such as 192.168.1.10, which gives about 4.3 billion addresses; the world ran out of freely available IPv4 blocks years ago, which is why techniques such as private addressing and network address translation stretch the supply. IPv6 uses 128-bit addresses, written in hexadecimal such as 2001:db8:acad::1, which gives a practically unlimited supply and removes the need for the translation workarounds.

For years IPv6 was described as the future that never quite arrived. That framing is now out of date, and this is the currency point most worth carrying from this section. In April 2026 the proportion of Google's users reaching it over IPv6 crossed fifty per cent for the first time, meaning most of the traffic to one of the world's largest platforms now runs on IPv6 rather than IPv4. Measurements differ depending on how they are taken; Google's own figure crossed half in April 2026, while APNIC Labs, using a different method, measured worldwide IPv6 capability at around forty per cent at the same time. The exact number drifts month to month and by country, so it is worth checking the live figure rather than fixing it here; the Google IPv6 statistics page tracks it, and the milestone was reported on the APNIC blog on 28 April 2026. The direction, though, is settled: IPv6 is no longer optional, and a network designed today is expected to run it.

The practical answer, and the one the unit's own scenario uses, is dual-stack: run IPv4 and IPv6 side by side on the same network so devices can reach both the older IPv4-only internet and the growing IPv6 internet. A dual-stack design assigns each device both an IPv4 address, typically from a private range such as 192.168.0.0/16, and an IPv6 address from an allocated block. Subnetting, the work of dividing an address block into smaller networks, is the same discipline in both: a block such as 192.168.1.128/25 or an IPv6 /48 is split so each department gets a subnet sized for its host count, with room to grow. It is fiddly arithmetic the first few times and then becomes routine, and it is worth practising by hand before leaning on a subnet calculator, because understanding why the numbers fall where they do is the part that lasts.

A working business network carries several kinds of communication, each with its own protocols. The delivered material lists them well, and they are still the right protocols to know. The important addition is that almost every one of them now has a secure, encrypted version that has become the default, and a current network installs the secure version rather than the plaintext original. This is the single biggest way the protocol material has moved, so it is worth going through the list twice: once as the unit names it, and once as it is actually deployed now.

Web traffic uses HTTP, and in practice always its encrypted form, HTTPS, which wraps HTTP in TLS. Plain HTTP on the public internet is now the exception, flagged by browsers as "not secure"; the current default is HTTPS everywhere.

Email uses SMTP to send, and POP3 or IMAP to retrieve. Each now runs over TLS: submission of outgoing mail on port 587 with STARTTLS, or on 465 for implicit TLS; IMAP over TLS on 993; POP3 over TLS on 995. The plaintext ports still exist but are the wrong choice for a new build.

File transfer uses FTP, which sends data, and often credentials, in the clear. Its secure replacements are SFTP, which runs file transfer over SSH, and FTPS, which runs FTP over TLS. A current network uses one of these rather than plain FTP.

Voice and video, carried as Voice over IP, use RTP and RTCP to move the media, with SIP or the older H.323 to set up and tear down calls. These increasingly run over encrypted transports as well, with SRTP for the media and TLS for the signalling.

Remote administration once used Telnet, which sends everything, passwords included, in plain text. Telnet has no place on a modern network; SSH replaced it and is the standard for secure remote access to network devices and servers. Device monitoring once used SNMP versions 1 and 2, which had weak or no security; SNMPv3, which adds authentication and encryption, is the version to deploy.

Underneath the user-facing protocols sit the ones that make the network work at all. DHCP hands out IP addresses automatically so devices do not have to be configured by hand. DNS translates names such as example.com into IP addresses. ARP maps IP addresses to hardware addresses on the local network. ICMP carries the control and error messages that tools such as ping rely on. These run constantly and mostly invisibly, and a fault in one of them, a DHCP scope that has run out or a DNS server that is not answering, produces symptoms that look like the whole network is down.

The theme of the section above deserves its own treatment, because the shift from plaintext to encrypted protocols is the clearest example of how this unit's material has aged, and a technician who installs the plaintext versions the older material lists is installing a network that would fail a current security review.

Transport Layer Security, TLS, is the protocol that encrypts most of this traffic. The current version is TLS 1.3, published in 2018 as RFC 8446, which is faster and simpler than its predecessors and removes a raft of old, weak options. The older versions, TLS 1.0 and 1.1, have been formally deprecated since 2021 by RFC 8996 and are disabled by default in current operating systems, browsers and servers. When someone says "SSL" today they almost always mean TLS; the SSL name is retained out of habit, but the protocol called SSL is long obsolete.

The web transport itself has a newer version worth knowing. HTTP/3, standardised in 2022 as RFC 9114, runs over QUIC (RFC 9000) rather than TCP, and QUIC runs over UDP, usually on port 443. This is a genuine change to the layering the older material teaches: a major web protocol that deliberately uses UDP, with reliability and encryption built into QUIC itself rather than borrowed from TCP and TLS separately. A technician reading a packet capture today will see QUIC traffic where a few years ago there would only have been TCP.

Even DNS, long sent in the clear, is being encrypted. DNS over HTTPS (RFC 8484), DNS over TLS (RFC 7858) and the newer DNS over QUIC (RFC 9250) stop DNS queries from being read or tampered with in transit. Adoption is uneven and, in a managed corporate network, sometimes deliberately controlled, because encrypting DNS also hides it from the organisation's own monitoring; this is a live tension rather than a settled question, and different organisations resolve it differently. But the direction, as with the rest of the protocol stack, is towards encryption by default.

Every protocol that runs over TCP or UDP uses a port number so that one device can run many services at once and know which incoming traffic belongs to which. The well-known ports are worth committing to memory, and the useful way to hold them now is in pairs, the plaintext port next to the secure one, because the move from one to the other is exactly the currency shift this page keeps returning to.

The authoritative list of registered ports is maintained by IANA in the service names and port numbers registry, which is the place to check rather than relying on memory when the answer has to be right.

At the transport layer sit two protocols with opposite priorities, and knowing when each is used is core knowledge for the unit. TCP, the Transmission Control Protocol, is reliable: it establishes a connection with a three-way handshake, numbers the segments it sends, waits for acknowledgement, and resends anything that goes missing. That reliability costs a little speed and overhead, which is why TCP is used where every byte has to arrive intact, such as web pages, email and file transfers. If a packet is lost, TCP quietly resends it, and the file still opens.

UDP, the User Datagram Protocol, is the opposite: it sends data without setting up a connection, without numbering, and without checking that anything arrived. That makes it fast and lightweight, and it is used where speed matters more than perfection and a lost packet is better dropped than resent, such as live voice, video and online gaming; a resent fragment of a phone call would arrive too late to be useful, so UDP does not bother. The interesting current wrinkle, mentioned above, is that QUIC builds TCP-like reliability on top of UDP, which is why the neat old rule "TCP is reliable, UDP is not" needs a footnote now: UDP itself is still unreliable, but a protocol running on it can add reliability of its own.

Between the end devices sit the intermediary devices that move traffic, and the unit expects you to name them and say what they do. A router separates networks and forwards traffic between them, choosing a path based on IP addresses; it is the device that connects a local network to others and to the internet. A switch connects devices together within a local network and forwards traffic based on hardware addresses. An access point lets wireless devices join a wired network. A firewall allows or blocks traffic according to rules, and is the main enforcement point for network security policy. A repeater or extender receives a signal and retransmits it to cover a greater distance.

The current versions of these devices carry a little more than the older material implies, and it is worth a sentence each. Many switches now operate at layer 3 and can route as well as switch. Firewalls have grown into next-generation firewalls that inspect traffic at the application layer and integrate threat intelligence, rather than only filtering by port and address. Wireless has moved through Wi-Fi 6 and 6E to Wi-Fi 7, and the security standard has moved from WPA2 to WPA3, which a current wireless design is expected to use. None of this changes what the devices are for; it changes what a current example of each one looks like.

Understanding a vendor's product range and its development direction is listed as required knowledge, and the reasoning is practical. The equipment chosen shapes what the network can do, so a designer weighs the current range against what is coming; a device due for release soon might bring a real improvement for a small extra cost, which could justify delaying part of a rollout, and a vendor that does not offer a full range of devices might force a mixed-vendor network with the interoperability care that brings.

The lifecycle side of this matters as much as the feature side, and it is the part the older framing understates. Network equipment has end-of-sale and end-of-life dates, after which it receives no more firmware or security updates; running a device past its end of support is a security risk, not just a support inconvenience, because unpatched network gear is a common way into an organisation. So the vendor conversation is not only "what is the newest model" but "how long will this model be supported, and how will its firmware be kept current". This connects directly to the unit's final performance criterion about storing and disposing of equipment: redundant equipment is disposed of according to manufacturer specifications and organisational procedures, which in Australia means following e-waste rules and wiping any configuration or credentials from a device before it leaves the organisation.

Installing protocols is, in practice, configuring addressing and services and then proving they work. A device gets its IP configuration either statically, set by hand and used for servers and infrastructure that must not change, or dynamically from DHCP, used for the general fleet so addresses are managed centrally. The core network services, DHCP for addressing and DNS for name resolution, are installed and configured on servers, and the client protocols are configured to use them. Much of the unit's practical work is done in Cisco Packet Tracer, a free network simulator from the Cisco Networking Academy that lets a student build a topology, configure devices and test communication without physical hardware.

Testing is a discipline of its own, and the tools are the ones a technician uses for the rest of their career. ping checks basic reachability using ICMP. tracert, or traceroute on Linux and macOS, shows the path a packet takes and where it stops. nslookup, or the more capable dig, tests DNS resolution. ipconfig, or ip on Linux, shows and renews a device's own configuration. netstat, or ss, shows active connections and listening ports. For anything deeper, Wireshark captures and decodes the actual packets, which is how a technician sees what is really happening rather than what should be happening. The pattern of a good test is the same each time: send known traffic, gather evidence such as command output or screenshots, and judge the result against the requirement rather than against a hope that it worked. The unit also expects the technician to seek feedback on performance and respond to it, which closes the loop between installing a network and confirming it actually serves the people using it.

One shift in thinking sits above the individual protocols and is worth knowing even at this level, because it changes how networks are designed. The old model trusted the network: anything inside the corporate firewall was treated as safe, and security was mostly about keeping outsiders out. That model has broken down, because users, devices and services are now spread across offices, homes and clouds, and there is no single inside any more.

The current model is zero trust, which starts from the assumption that no network location is trustworthy and checks every request on its own merits: who the user is, whether their device is healthy, and what they are trying to reach. In network terms this shows up as segmentation, dividing the network into zones so a problem in one cannot spread freely, and increasingly microsegmentation, tightening that down to individual workloads. It also explains, from another angle, why so many protocols are now encrypted by default: if the network itself is not trusted, the traffic on it has to protect itself. A technician installing protocols today is, whether or not the word is used, building the encrypted, segmented plumbing that a zero-trust design assumes.

The unit says nothing about artificial intelligence, because when it was written there was nothing settled to say. It would be easy to force an AI section onto a protocols unit and add nothing real, so this one stays close to what actually touches the work.

The honest change is on both sides of the network. On the defensive side, the move to encryption described throughout this page has a side effect: when traffic is encrypted end to end, the old approach of inspecting packet contents for known-bad signatures no longer works, because there is nothing readable to inspect. So detection has shifted towards analysing the shape of traffic, the timing, sizes and patterns of encrypted flows, rather than their contents, and machine learning is the tool doing much of that analysis. A technician will increasingly meet network monitoring that reasons about behaviour rather than reading payloads. On the offensive side, the same techniques that industrialise other attacks apply at the network level, from automated scanning and fingerprinting to faster discovery of misconfigured or unpatched devices, which is one more reason the equipment-lifecycle point above matters.

Closer to the daily work, AI assistants have become a common way to design addressing schemes, generate device configurations and interpret packet captures or error messages. They are genuinely useful for this, and they are also confidently wrong often enough that the discipline is the same as with any tool: a generated configuration is checked against the actual device and the actual requirement before it is trusted, because a plausible but wrong subnet mask or access rule fails silently and can be hard to trace later. The durable skill the unit teaches, understanding what the protocols actually do, is exactly what lets a technician tell a good AI-generated answer from a bad one; the models are an accelerator for someone who understands the network, and a trap for someone who does not.

These notes were built from the delivered ICTNWK311 material in the unit folder, principally the assessor guide and the training.gov.au unit descriptor generated by the Future Skills Organisation on 17 December 2024, which supplied the elements, performance criteria, foundation skills, performance and knowledge evidence and assessment conditions used in the scope block and to decide coverage.

The currency material was verified in September 2026 against primary sources. The IPv6 adoption milestone is from the Google IPv6 statistics page and the APNIC blog post "Google hits 50% IPv6" of 28 April 2026, which also gives the APNIC Labs figure of about 40 per cent measured by a different method; the two are presented as the grey area they are. The protocol standards are the IETF RFCs cited inline: TLS 1.3 (RFC 8446), the deprecation of TLS 1.0 and 1.1 (RFC 8996), HTTP/3 (RFC 9114), QUIC (RFC 9000), DNS over HTTPS (RFC 8484), DNS over TLS (RFC 7858) and DNS over QUIC (RFC 9250). Port numbers are checked against the IANA service names and port numbers registry. The practical tools are Cisco's Packet Tracer and Wireshark. All links were read in September 2026.