Spamming, NAT, Switching and Labels

January 2001 was a big month, if you’ve been waiting for the official publication of the core Multiprotocol Label Switching (MPLS) specifications. Though several RFCs have been published over the past few years that were peripherally about MPLS as well as its precursors, the foundational specifications on MPLS and the Label Distribution Protocol (LDP) have finally been released. Table 1 lists the January RFCs.

Other interesting RFCs released in January include a couple of Informationals about Network Address Translation (NAT) as well as a nice new Proposed Standard for Sieve, a mail-filtering language that is positioned as both easy enough for end users to use to sort mail on their clients and powerful enough to help network administrators stop spam at their servers’ front door.

Table 1: January 2001 RFCs


Unsolicited commercial email (UCE) or unsolicited business email (UBE)–whatever you call it, spam is a major nuisance. It clogs mail servers, fills client mailboxes, and generally makes life difficult for users and network administrators.

Most mail programs, whether for clients or servers, provide some mechanism by which the end-user or netadmin can filter out the junk and sort the rest. However, the filters you set up for a Netscape Communicator user aren’t easily transferable to Qualcomm Eudora, Microsoft Outlook, mh (on UNIX systems), or any other email client.

This sounds like a job for the IETF: Come up with a standardizable mechanism for email filtering. Sieve is the answer, as described in RFC 3028, “Sieve: A Mail Filtering Language.” Sieve is a very simple programming language designed to be just powerful enough to filter mail, but not so powerful that it can’t be safely deployed on a server. There are no variables and no loops, but they aren’t necessary for Sieve’s defined purpose.

Although Sieve could be an excellent weapon in the constant battle against spam, it must win acceptance in the marketplace. So far, there are few implementations. The biggies, including Microsoft and Lotus, seem to be waiting for consumer demand before they incorporate Sieve in their mail programs, though Cyrusoft International, Inc., does offer Sieve in its mail software. A Sieve resource page is available at


For some people, network address translation (NAT) is far more annoying than any gnat could ever be. For others, NAT is a tool that lets us continue the day-to-day operations of the Internet without interruption and without having to drop everything and upgrade (or migrate) to IPv6.

Basically, NATs let organizations and individuals use a single globally unique IP address as a front for an entire private network. Using three ranges of IPv4 addresses that have been reserved for private networks (meaning that anyone can use them, as long as they aren’t connected to the global Internet), NATs actually translate IP headers originating inside the private network into a form that can be routed through the public Internet using the single official IP address. Headers of inbound packets are also translated, so they can be delivered to the correct host on the private network.

RFC 3022, “Traditional IP Network Address Translator (Traditional NAT),” is an Informational document that updates the definition of NAT provided in RFC 1631. This is a good starting point for anyone interested in how NATs work, what they are, and what they can do.

If you want to know why NATs are anathema to Internet purists and practicing network engineers, read RFC 3027, “Protocol Complications with the IP Network Address Translator.” This Informational explains why NATs break applications. The authors begin with a discussion of the attributes of applications that might cause them to not work with NATs. For example, if a protocol requires certain parts of the header to be echoed within the packet payload, it cannot work with NAT, which changes header fields.

Anyone thinking of using NAT, or anyone who must understand how to support applications being used across NATs, should read this RFC. It includes lists of Internet applications that are totally broken by NATs (including IPsec, IKE, Kerberos, X windowing, and r-utilities), applications that can work with NAT if you deploy an application layer gateway as well (including FTP, RSVP, DNS, SMTP, SIP, RealAudio, H.323, and SNMP), and the single application protocol that has been designed to operate happily across a NAT (the Activision Games protocol).

Switching and Labels

IP and ATM are two dissimilar protocols that solve roughly the same problem: linking nodes on sometimes very large networks. IP focuses on routing, operates at the network layer rather than the link layer, and can be said to use relatively dumb devices to make the network itself “smart.” ATM, on the other hand, focuses on switching, operates at the link layer, and uses “smart” devices that switch data across dumb networks. Both have advantages, with IP having the edge in terms of reliability and robustness, while ATM tends to be faster.

The Multiprotocol Label Switching (MPLS) architecture makes it possible for ATM and other non-broadcast, multiple access (NBMA) network protocols that rely on virtual point-to-point circuits, like Frame Relay, to move IP traffic. Under MPLS, devices on the edge of the NBMA network assign inbound IP packets a Forwarding Equivalence Class (FEC) based on their destination addresses. This FEC is encoded as a “label,” which is used by switches in the network to make decisions about where to send the packet.

Each switch looks up the incoming packet’s label on a switching table to determine where the packet should be sent and what new label to give it. This process allows very fine control over how packets are handled within the MPLS network: The decision about how to treat the packet is made at the ingress point, and once inside, the packet is switched appropriately. MPLS permits the ingress switch to use any information about that packet to make this decision, so Quality of Service (QoS) issues can be brought to bear, allowing some packets from the same source and going to the same destination to be given different switched paths through the network.

The MPLS and related RFCs published in January constitute the core specifications for MPLS, including the MPLS architecture (RFC 3031), the Label Distribution Protocol or LDP (RFC 3036), and use of MPLS on ATM (RFC 3035) and Frame Relay (RFC 3034).

Although some of these documents were approved for publication well over a year ago, they could not be published as RFCs until all normative references (references to aspects of the specification documented elsewhere that define the Proposed Standard) were published as permanent documents. Until all the related (and temporary) Internet-drafts were published as RFCs, none of them could be published as RFCs.

With MPLS, network engineers are finding new ways to maximize the benefits of ATM and Frame Relay to speed IP data across the Internet. The publication of these RFCs firmly places MPLS and LDP on the standards track.

What’s Next

Some interesting new RFCs came out in January, but February looks to be even: A flurry of new RFCs, document and protocol actions, and four new working group approvals came in during the first couple days of the month. Check back in a couple of weeks for the latest about IETF working groups (a few old ones have closed, but as many as a dozen new ones are open for business or in the pipeline), as well as other developments; we’ll cover February’s RFCs in the first week of March.

And, if you haven’t made your reservations for IETF 50 in Minneapolis (March 18-23) yet, you’d better do it soon. //

Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of, Pete frequently consults on Internet protocol issues.

Latest Articles

Follow Us On Social Media

Explore More