IETF 98 Chicago: Homenet, and the hunt for a name

By on 30 Mar 2017

Category: Tech matters

Tags: , ,

Blog home

During IETF 98, I attended the Homenet Working Group. Homenet is exploring the design of… well, the network of future homes. Not just any home but a home with hundreds of devices, far far more than we have right now (I currently have only 10 devices that are regularly online).

An important consideration for such homes is that they will very probably have more than one connection between the house and the global Internet. You might have a network just for:

  • connecting your TV and phone
  • managing your power, gas and water
  • your children, which would have moderated accessibility

All of these have to co-exist, all of them have to be as painless as possible to configure and run, and, critically, they need to work reliably with one another.

But what about name-based services?

Attending this Working Group, I had to promise myself to be on my best behaviour, because I have been a partisan in a conversation about how to find a name, to hang locally managed things on, for name-based services.

What follows is a personal opinion and I apologize if I offend anyone by mischaracterizing their side of a disagreement, and invite them to contribute their response here on the APNIC blog.

The idea of Homenet, and the multiple networks and network connections it creates, is to do it with as few hands on the tiller as possible: Auto-configuration, and lots of it. However, it has its limitations when it comes to human interaction.

Consider how you currently print over a network. If it’s a local network it should be fairly simple to locate your printer on the network, select it, and print. But imagine your network has four, or more sub-networks. Some print models won’t do auto-discovery over this routing architecture.

To solve this, you need to build out name-based service discovery, which can be agile across the different subnets – printer.homenet is where you’ll find your printer.

But – and it’s a big ‘but’ – those who have been involved in these discussions have tried really hard not to just assume .homenet is ‘the one’. This relates to previous discussions where people used .local and a huge argument ensued over many meetings about ‘who said you could do that’. The end result was the adoption of a process, subject to a memorandum of understanding between the IETF and ICANN, on how to ask for ‘special’ names. A process so fraught, it was shut down.

But, Homenet is knocking at the door. They think they have a sound reason for wanting a top level name, perhaps less ‘technical’ than I might like, but it has been argued with some passion, this is a special-case name, and they want to ask for one. And, it should be human-friendly.

Enter the argument.

I am (as I said) a partisan in this discussion. I don’t like RFC6761, and I don’t like the implications of having a special-pleading mechanism into what ICANN do.

I’d much prefer to see a name like homenet.ARPA selected, which lies under a 2LD, beneath a domain already delegated to the IETF process – the one we use for reverse-address registration among other things.

But, to be fair, I cannot deny the attraction of the name they want, to the community of interest they’ve identified, with one qualifier. It is a rather anglo-centric choice: it presumes the label should be in English. I wonder, if this actually reflects the community well? Should it not maybe be an emoji or, perhaps, we need to have homophones?

Perhaps the goal is not to have .homenet at the top but to understand we need a name, which works no matter where you are. This is the crux of the problem: how do we tell software NOT to look for this name in the global name space. Because that’s not what the global name space is for, it’s to name things, which only lie in the LOCAL name space, outside the system.

There are some real technical issues lurking underneath this problem, which are big, scary arguments between different world views. It’s not going to be solved by ignoring it. Instead, we have people like Brian Trammell from ETH Zurich who are asking the even bigger question: what do we actually want from the name service?

The problem is real and is spread across several groups. It’s going to bounce from HOMENET WG to DNSOPS (it already has, twice) and then back into the IETF open discussion, the IESG, the IAB, the appeals processes; it’s going to be a real popcorn event. Watch this space!

Update 31 March 2017:
Sometimes, things work out faster than you think.
I wrote this post in the heat of the moment coming out of HOMENET and DNSOPS, as a participant in one, and a silent witness in another. At the time, I believed we were in for a protracted debate and probably some overt list activity.
Well, I was wrong: what we saw, from the AD intervention – which was handled very carefully and I think remarkably well by Terry Manderson – was a clear, and careful signal of choices, one of which included the .ARPA name above the .homenet label.
It turns out that the IESG, the IAB and the related discussion addressed this, and we have now been given a clear indication by the IAB of their desire to avoid contention with ICANN, push back on the WG, and flag .ARPA as the preferred location for special-use names. As posted to the mail list:

In the view of the IAB, when placing any name in the Special-Use Domain Names registry with the intention that it be used with the DNS protocol, such an entry must be within a domain under the control of the body making the registration. For the IETF, an appropriate domain for such names would be ARPA, as long as those names meet the conditions in RFC3172.

As I stated in my post above, I am a partisan in this debate. I think the IAB made the right decision, and I thank them both for the speed, and the clarity of the declaration.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please answer the math question * Time limit is exhausted. Please reload CAPTCHA.