One thing that I think the working group should be aware of, although I don't know if this awareness will change anything, is that the situation with the .homenet allocation is less simple than we would prefer: it's not really simply a matter of adding .homenet to the special use domain names registry. The reason is that we need DNS resolution to work properly for domains under .homenet, and this has to work even if a host is doing DNSSEC validation.
At present, if you were to configure a homenet router with .home or .homenet as the local domain, this would work perfectly nicely until you turned on DNSSEC validation, at which point all the names in either hierarchy would disappear. The reason for this is that the root zone provides proof of nonexistence for nonexistent names in that zone. It is possible to address this problem by requesting ICANN to put an insecure delegation in the root zone. The problem is that from a process perspective, this is a _lot_ more heavyweight than doing a special-use domain name allocation, and has no guarantee of success. This wasn't such an issue for .onion when we did it, because .onion _wants_ a secure denial of existence--we _never_ want a .onion query to actually happen if the name has been handed to a resolver that doesn't understand .onion explicitly. This is not true for .homenet. There are two approaches we can take to this. One is to proceed--ask ICANN to do the delegation and see what happens. The other is to take the more expedient, less satisfying approach: use .home.arpa instead of .homenet. I'm not in love with this as an end solution, but it has the advantage that the IAB controls .arpa, and so we can get an unsecure delegation right away assuming the IAB agrees. I see no reason to think they would not. It's a bit more typing, and there is the problem that the fourth google result for arpa is "Advanced Research Projects Agency. But it would work, and quickly, and would keep the whole process in the family. The other alternative is to continue with the original plan: do the special-use names registry allocation, and send a liason to ICANN asking them to do the unsecure delegation. The downside to this approach is that we won't know whether the outcome will be success or failure for a long time, possibly several years. And the outcome could very well be failure. The upside is that we get the name we all want; the downside is that we are a long way down the road with no win. I should point out that whichever way we go, we already have solved the immediate problem: we have a name that HNCP can use, the potential liability for IETF is dealt with, and our prototypes can be made to work. So I am personally okay with either decision. Our AD, Terry, may have more of a sense of what ICANN will do (but to some extent he really can't know, because it's up to committees within ICANN to actually make this decision). I'm mentioning this now not to derail the process, but simply to make it really clear what our expectations should be. The reason that this didn't come up in Seoul is that it didn't actually click for me that we had a serious problem until several of us were chatting on the way out of the room, after the working group had already decided to proceed. On Thu, Dec 1, 2016 at 9:02 AM, Ray Bellis <[email protected]> wrote: > > > On 21/11/2016 13:25, Ralph Droms wrote: > > (Updated comments on draft-ietf-homenet-dot originally posted prior to > the WG last call) > > Thanks Ralph. > > I'd like to remind the WG that the LC is due to run until Friday > December 16th, so please anyone else with comments please get them in. > > Ray > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
