Odds and Ends – IETF 88 Part 4 – Guest Blog by Cathy Aronson [Archived]

By Jennifer Bly

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

ARIN Advisory Council member, Cathy Aronson, was at IETF 88 in Vancouver, BC, Canada last week. Follow along as she continues to share her findings with us on TeamARIN!

Guest blog post by Cathy Aronson

IRTF - Internet Research Task Force

On the last day of IETF I went to a group of the IRTF. It was the Network Management Research Group. I have to confess I haven’t paid much attention to this group so I wasn’t really sure what they have been working on. In my mind that morning when I decided to attend that group I thought maybe they would be solving the age old network management problems. What do I think that is? Well it is still mostly the case that network management systems (NMS) monitor the network and can usually only tell you when something is down. They can’t usually tell why it is down. To me that is the age old problem of network management. So off I went to this installment of IRTF.

The group is not working on my age old problem with network management. They are working mostly on autonomous networks. So basically making the network configure itself and adapt to changes. The theory is that minimizing human futzing with the network will make it more reliable.

One draft was Network Configuration Negotiation Problem Statement and Requirements. The premise here is that network devices should be plug and play, less hierarchical and less dependent on humans. An example they used was that two CGNs might want to negotiate to switch around which IPv4 address blocks they’re using based on traffic and time of day. The example was horrible because it wasn’t a bit aligned block of addresses and it also had the CGNs connected via the Internet instead of being on the same network. In this case the address block would have been too small to be advertised on the global Internet. I suggested they fix the diagram.

There were two other documents describing a framework and implementation of these autonomous networks. I explained my personal concerns about managing all these autonomic networks. I am not sure that the folks doing this work manage large networks.

The other document is Bootstrapping Trust on a Homenet. This was super interesting. The idea is that your home network would figure out its boundaries and build a trust model. So if someone else plugged a device in it would have to be approved to connect. The scenario described was one where a home user brings home a router. They use their phone application to scan the barcode on the box and it has all the information needed to build a trust model in the home. The phone application would then notify the user if something new connected and give the home user the opportunity to say yes or no regarding its use on the network. In this way the home network would know its boundaries and what was inside and outside.

Some more odds and ends from IETF

In at least one of my previous ARIN talks about IETF I mentioned Igor’s draft. The document is now an RFC.

This is the one that describes a problem with the default subnet size in IPv6. The size is a /64. This is 18,446,744,073,709,551,616 addresses. It’s huge. The average subnet size in IPv4 is 254 usable addresses or a /24. There are denial of service attacks that could happen if someone scanned a port range that large. The devices on the LAN have to deal with the requests even though most of the subnet is most likely empty.

In the Benchmarking Methodology group there is now a draft that addresses this issue. This document provides a test methodology to see what happens in this scenario. At least now it’s possible to see how different networking devices might handle such a scan or just how they may handle a subnet that big.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.