Networking

The gems you find in RFC's

In the last 18 months we have been doing a lot of design, development and delivery of training in the area of Carrier Ethernet (CE). Especially in the world of carrier networks there is the need to pro-actively manage the quality of service (QoS) and network performance, which normally goes under the name Operations, Administration and Maintenance (OAM) functions. To ensure conformance with QoS metrics and design build, test methods need to be constructed to provide rigor to the acceptance testing process. And, there is a number of publications from different standards bodies that provide guidance on the testing process...and this raises the question which do you follow, because we have the International Telecommunications Union (ITU), working some aspects and the Internet Engineering Task Force (IETF) - Request For Comment (RFC) working other paths.  So, you may well ask is there consensus between these standards' groups, and in RFC 6815 you will find this gem (page 7, para 3) of an answer:

"The world will not spin off axis while waiting for appropriate and standardized methods to emerge from the consensus process."

You may be interested in referring to some of the network performance documents. The documents include from the IETF - RFC 2544 - Benchmarking Methodology for Network Interconnection Devices http://www.ietf.org/rfc/rfc2544.txt. Published in 1999 this is still a topical document providing various test conditions, frames sizes and rates. The ITU Study Group 12 published in 2011 an Ethernet service activation test methodology in the document, SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Internet protocol aspects – Quality of service and network performance (See http://www.itu.int/rec/T-REC-Y.1564/en ). This was intended to fill the gaps in measurement methodology (with respect to RFC 2544) given the evolution of Ethernet services in the telecommunications carrier space.

In November 2012 the IETF published Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful (See http://tools.ietf.org/html/rfc6815 ) The title says it all, with the intention to clarify that RFC2544  was  only for use in isolated test environments and not for production networks.

 

The computer that doesn't crash

It is virtually impossible to maintain a high tempo exploring and keeping abreast of the churn and chaos in the technology space, and then translate that into meaningful training solutions. We often see technology following the creative masterful minds of popular  sci-fi and futurist writers (look at the LG GD910 wrist phone/watch, or the new Pebble and recall the Dick Tracy series). And, now we are seeing the emergence of computers that never 'crash'.  This was the subject of an article that caught our eye published last week at newscientist.com. Cyborg self healing, 2001 Space Odyssey just around the corner? For now it is watch this space.... http://www.newscientist.com/article/mg21729045.400-the-computer-that-never-crashes.html

 

IPv6 Prefix Delegation and Firewall Rules

Many service providers will supply their customers with a block of IPv6 addresses using DHCP based Prefix Delegation. This is described in RFC 3315.

When configuring your traffic filter or firewall on your router, you will need to remember to allow DHCPv6 traffic on your outside interface.

DHCPv6 uses UDP port 546 client side, and UDP port 547 on the server side. As it will be your WAN interface that is behaving as the DHCP client, you will need to:

  • allow OUTBOUND traffic with a SOURCE port of 546 and a DESTINATION port of 547;
  • allow INBOUND traffic with a SOURCE port of 547 and a DESTINATION port of 546.

Without these rules, you won't get a prefix and there'll be no IPv6 for you!