Re: [homenet] tunnels as way to disambiguate .local
On 07/08/2012 20:11, Michael Thomas wrote: On 08/07/2012 11:46 AM, Kerry Lynn wrote: On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt e...@isc.org wrote: Tunnels are okay, but to use them, but has to get the DNS search order and the DNS server list right, and that's walled garden territory. *If* we are going to turn each home into a walled garden, then let's be aware that we are doing that. I'm of the opinion that in a walled garden scenario, the tunnel endpoint may be the only resource that needs a global name / address. Just checking, but we all think that naming is a separate issue from reachability, right? It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps especially section 4.2 FQDNs are not sufficient. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Wed, Aug 08, 2012 at 01:03:11PM +0100, Brian E Carpenter wrote: It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps especially section 4.2 FQDNs are not sufficient. I thought one of the things we were trying to do was to address exactly the failure modes in that section of the I-D? Perhaps I'm being naive, but I've been working from the assumption that, if you want to talk to something on the Internet, you need an unambiguous way to identify it. Historically, the best we've had for that has been the DNS, because it provides a layer of indirection so that you can have stable identifiers in the face of changing IP addresses. Given the way the relevant markets have gone, it turns out that DNS names are rather harder to administer and use for ordinary end users than we might like. But there's no reason that has to persist, and it seems to me that if we're going to solve the problems people have using homenet-type resources on the global Internet, then solving the DNS piece in a user-friendly way is going to yield greater benefit than alternatives like ginning up some trick to make mDNS names sometimes work outside their natural context. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 5022557f.5050...@gmail.com Brian E Carpenter writes: On 07/08/2012 20:11, Michael Thomas wrote: On 08/07/2012 11:46 AM, Kerry Lynn wrote: On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt e...@isc.org wrote: Tunnels are okay, but to use them, but has to get the DNS search order and the DNS server list right, and that's walled garden territory. *If* we are going to turn each home into a walled garden, then let's be aware that we are doing that. I'm of the opinion that in a walled garden scenario, the tunnel endpoint may be the only resource that needs a global name / address. Just checking, but we all think that naming is a separate issue from reachability, right? It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps especially section 4.2 FQDNs are not sufficient. Brian Brian, MIF may be trying to solve the problem the wrong way. Providing a mapping of DNS to loopback address has long been used (by routers) to provide a stable reachable address. The routing cost to reach that loopback interface (which can change many times for an active connection) is used to determine which physical interface gets used to reach the loopback. For example if one interface is connected to an ethernet which gets isolated due to a router failure, the other interface is used because routing tells us that one of them is unreachable. Multihoming of course pokes holes in the routing tables and causes some routing table bloat. This has always been a problem and IPv6 does nothing to improve the situation that existed in IPv4 two decades ago with a lot of small providers and large enterprises using dual provider multihoming. If we are concerned with hosts that have multiple interfaces both leading to parts of the homenet, that is easily solved. Multihomed homenets is a whole different problem, but solvable if redundancy is to the same provider. A conditional static route can be advertised within the provider, with these routes having limited scope (for example using BGP communities). If this practice were to become commonplace (I doubt it, no consumer provider has that sort of redundancy in the last mile), then the provider would have to limit the scope of these more specific routes to a small subset of their own topology. I get the impression that if NAT didn't exist, then draft-carpenter-referral-ps would server no purpose. Is this draft entirely motivated by problems caused by NAT? Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Ray, I agree with the intent of RFC6281 aka Apple BTMM, although not with many of the details of the implementation. I agree that syncing mDNS and DNS might be difficult and I propose we avoid using mDNS. A compromise is if a FQDN exists in DNS, both DNS and mDNS return a CNAME to the FQDN for local or sitelocal queries. A bad assumption is that anything on the same subnet deserves some level of trust just as a matter of having been connected to that subnet. The BTMM builds on this bad assumption by providing a means to make it appear as if remote hosts are on the same subnet or at least site by effectively using ULA as a host ID and tunneling the ULA of the remote machine. A much better way of doing things would be to use a GLA if available, particularly for IPv6 where no NAT should ever be needed. For security, on the same LAN segment or not, exchange some credential, such as a private key. This could be done at home the way most *ix people do it (put on USB stick and copy, exchange some insecure way with fingerprint verification, respect key signing by a trusted entity, etc), or for the more typical homenet customer with an insecure transfer encrypted with a shared secret (same password typed in two places, where one place could be the web page used to configure the consumer oriented junk such as printer). Delegating a sub-domain is a necessary part of any good solution that involves remote access to the homenet. sitelocal is different everywhere. ula.ula-based-sitelocal is unique but available only at the site. We (both in the IETF and in consumer product worlds) sometimes stand on our heads trying to work around horribly insecure home and office devices and practices that are hidden behind firewalls. Using firewalls has been proven time and again to be ineffective. In the office, one compromised PC can compromise an entire enterprise or at least the subnet it is on if weak security is in use behind the firewall. Same at home if Mom shows up with her old windows98 PC and an equally old PCMCIA 802.11a/b card. How may of us have been in an office where an email from IT explained that the current local network slowness is due to very high virus activity (behind the firewall!) and fear not because IT is on it? If there is a way to discover the ULA being used at a local site, then printer3.ula.ula-based-sitelocal is functionally equivalent to printer3.sitelocal - either way it is the printer that is found if you ask for printer3 and you (or cups) don't specificy a FQDN that you learned earlier. If the first printer3.sitelocal was a CNAME for a FQDN, then an application could cache the mapping of printer3 to that FQDN or at least inform the user of the FQDN or inform the userwhen specifying printer3 results in a different FQDN than previously. Curtis In message 501e199a.4060...@globis.net Ray Hunter writes: I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. I'm talking about using the ULA to generate a HomenetID for use in the namespace. See RFC6281. The HomenetID and DNS subomain (or as you put it somethingveryobscure) may be generated by one unique host (e.g. each Homenet border router) based on a ULA. But that does not mean it cannot be discovered by all hosts and routers in the Homenet (via some bunch of discovery mechanisms such as automatic prefix distribution for router-router and DHCPv6 for router - fridge). The HomenetID will remain constant as long as the ULA of the border router remains constant. If it appears to vary (because the border router changes) then highly mobile nodes will get some indication that they may not be connected to their own Homenet, and ask for user input to accept an update. Static nodes would only know their local HomenetID, and if it changed they could be set to always accept the update without user input. Eventually you would probably end up with a search list linked to the number of border routers the end node has ever encountered, but end nodes can automatically age out old entries. We might also want to be able to manually override the auto-generated HomenetID to cover the case where border router hardware is replaced by the user, but that's no different to MAC address cloning on CPE's in the past (where ISPs used the MAC address of the CPE as an identifier in management systems). Sure there's a downside in complexity of the namespace. The potential upside of this approach is that the same somethingveryobscure.sitelocal. zone file could also be mounted as a secondary on somethingveryobscure .ISP DNS root or somethingveryobscure .employer's DNS root if the ISP or enterprise wished to provide this service for global name resolution. Highly mobile nodes would only need two items in their DNS search list, the search list can be pretty much auto-generated, and they can use the same name resolution technology (DNS) wherever they are located. It
Re: [homenet] tunnels as way to disambiguate .local
On Mon, Aug 6, 2012 at 9:39 PM, Evan Hunt e...@isc.org wrote: On Mon, Aug 06, 2012 at 04:33:49PM -0400, Michael Richardson wrote: No, the fridge must have a globally reachable address (GUA) to be reachable. You are correct, of course, and I was being unclear; sorry about that. I was trying to reflect what I thought I heard in the discussion in Vancouver, though, which was that a FQDN or the equivalent would be the best way to handle naming of remotely accessible devices. It seemed to me that we had rough consensus on that point (perhaps I was mistaken), but not on naming of devices on island networks. Tunnels are okay, but to use them, but has to get the DNS search order and the DNS server list right, and that's walled garden territory. *If* we are going to turn each home into a walled garden, then let's be aware that we are doing that. I'm of the opinion that in a walled garden scenario, the tunnel endpoint may be the only resource that needs a global name / address. I note that dyndns supports a wide-area DNS-SD beta (ability to populate PTR, SRV, and TXT RRs) and I'm going to look into this approach as an alternative to BTMM. For the purposes of my mom's house, I do think walled garden is the appropriate default setting, but our design should allow the default to be overridden without great difficulty. I am generally supportive of this approach; certainly it would focus the discussion between now and Atlanta. I think this general plan would meet those goals: 1) All discoverable devices on all networks MUST answer to a locally reachable name, such as devicename.local, devicename.sitelocal, devicename.networkname.local, devicename.ULA, devicename-ULA.local, etc. (We haven't settled the naming convention here. I personally like devicename.networkname.local, with devicename.ULA.local as a fallback in the event of the network's owner failing to configure a network name); +1, with the caveat that .local. has special semantics (multicast DNS-like requests to FF02::FB, port 5353) defined by http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns 2) Networks configured to allow remote access to devices SHOULD have a globally reachable domain name, either owned by the user or in a vendor-managed namespace; I'd like a bit more explanation re: this requirement. In general it seems there is no relation between a network and a domain name. Exceptions would include .local. (maps to the local _link_, and therefore to the prefix(es) assigned to that link; or domains ending in .in-addr.arpa.. http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd section 11 has a method for determining the preferred registration zone(s) based on a host's address. 3) If a device is configured for remote access and is on a network which has had a FQDN configured as in (2), then in addition to the locally reachable name described in (1), the device MUST also answer to devicename.FQDN. I like to see us reserve FQDN for host names that are registered in the global DNS namespace, and use LQDN (or some other alternative) for host names in locally served zones. Any support for this? -K- -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On 08/07/2012 12:54 PM, Michael Richardson wrote: Michael == Michael Thomas m...@mtcc.com writes: Michael Just checking, but we all think that naming is a separate Michael issue from reachability, right? It's separate. The question is: does the set of names you can resolve depend upon the connectivity that you have? (the reachability) I think that this is a form of security through obscurity, and I'd rather that the various carriers who want to impose walled gardens on their video-over-3G-to-smartphone systems (causing changes up to the application layers) would do something different. As a security property was mainly what I was getting at. We're not thinking that .local is bringing us anything on the security front wrt reachability (privacy being a different issue). So it seems we all hopefully agree. Now what to with about the privacy issue... bletch. .local[site] has similar considerations along those lines it seems to me, though the mechanisms are different confusing the issue even more. Mike I overheard a snippit of conversation last week from Lorenzo about what Android will be doing to support walled garden DNS. I can't repeat it, because I didn't hear the answer... ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Tue, Aug 07, 2012 at 12:11:40PM -0700, Michael Thomas wrote: Just checking, but we all think that naming is a separate issue from reachability, right? Separate, but in the context of recommended configuration for home networks under the control of non-geeks, I'd say they're related. In that context, we would like reachable devices to have names, and we would like devices that are reachable remotely to have names that are resolvable remotely. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 8857.1343917...@obiwan.sandelman.ca Michael Richardson writes: Brian =- Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian Correct, but the name is unambiguous, which IMHO is a MUST Brian property for anything that looks like an FQDN. We have to Brian live with .local but it should be just a nasty memory like Brian 10.0.0.0/8 fifty years from now. Brian I would suggest instructing IANA to reserve all TLD strings Brian that start with local and using something like Brian .local-fd952a92a67d to name the homenet domain. It's only a Brian convenience to use a ULA prefix; it's simply a unique string Brian that the CPE needs to generate anyway, but it has no Brian significance beyond that. huh, you want to do it that way? Why not fd952a92a67d.local? I'm asking for clarification, not disagreeing. Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works I'd prefer mDNS returns a mapping of printer3.local to a CNAME printer3.fqdn and DNS returns a mapping of printer3.sitelocal (or localsite if you prefer) to CNAME printer3.fqdn. In both cases, if there is a subdomain delegated by the provider, then fqdn is that subdomain, and if no subdomain has been delegated, then the fqdn is of the form ula.local (ie: fd952a92a67d.local in your example). An application can (though none today do, cups for example could be changed) obtain the query results using the partial domain name (ie: printer3) and gethostbyname2 to get an address and then use gethostbyaddr to do an rDNS lookup to get the FQDN if printer3.sitelocal was first in the DNS search path. If the mapping from printer3.sitelocal were to change, the user could be given a choice to use the new printer3.sitelocal or use the old one through the FQDN. Multiple mappings of printer3.sitelocal could be retained, such that printer3 yielded a list each time a request was made to print using this unqualified name. Of course that would mean rDNS would have to work. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On 06/08/2012 04:28, Evan Hunt wrote: i wasn't able to participate in this discussion because I had other business during homenet, but I'm a bit frustrated by this conclusion. I was speaking for myself and I believe the issue is in flux; please don't take it as a conclusion. :) IMHO, we shouldn't promote bad solutions, and .local is a bad solution. IMHO .hexidecimal-gibberish is also a bad solution. It's, at least potentially, a worse one: you buy a new router, and suddenly your devices all have new names and your bookmarks don't work. To make them work again, you have to remember the hexidecimal-gibberish that was assigned by your previous router and configure it to use the same one. Ugly. I do agree that expecting ordinary users to keep track of a pseudorandom string is unreasonable. Maybe we can take a hint from mailman. When you install a new CPE router, and it's unable to discover the current unique string, you could be asked to enter your existing unique string, but also be offered the option of the router creating a new one. So the requirements seem to be 1. A discovery mechanism so that new devices on a homenet can find the local unique string. 2. The string and the discovery mechanism need to survive a cold start and the replacement of the CPE router (in all scenarios except a factory reset). That means a distributed solution. 3. If there really is no unique string, the CPE router generates one, unless the user prefers to type it in. Undoubtedly .sitelocal is simpler. Brian I'm not really happy with either of these choices, but I'm less unhappy with .sitelocal. Whether we come up with some way to leverage a ULA to present things sensibly in some UI is another question, but if we are trying to come up with a solution for geeks, why not come up with a _real_ solution, instead of the .local hack? I'd love to hear the plan. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Aug 5, 2012, at 11:28 PM, Evan Hunt wrote: I was speaking for myself and I believe the issue is in flux; please don't take it as a conclusion. :) Fair enough. :) IMHO .hexidecimal-gibberish is also a bad solution. Yes, definitely. If that gibberish is ever visible to the user, we've done it wrong. It's, at least potentially, a worse one: you buy a new router, and suddenly your devices all have new names and your bookmarks don't work. To make them work again, you have to remember the hexidecimal-gibberish that was assigned by your previous router and configure it to use the same one. Ugly. Even forgetting the hexadecimal gibberish, if there is any sort of local name that is based on the router, switching routers is always going to be ugly. Ideally we want the solution to be tied to something in the cloud so that the replacement router can restore its brains. I'd love to hear the plan. For geeks, you register a domain, or pay a small monthly fee for a subdomain of something like dyndns.org. Maybe the brains for your router live there too, so that if you replace it, you can just punch in your domain, and it figures out the rest. This works for geeks; everyone else uses friendly names presented in a UI. Of course, I also think that ULAs ought to be allocated rather than guessed at, which I gather is not a popular position. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Aug 6, 2012, at 12:58 AM, Unindicted Coconspirator wrote: Domains like .local seem like a good idea to geeks like us, but how many regular users ever use them? Every single user who has added a printer to OS X or Linux in the last several years. No. You think that because you're a geek like the rest of us. Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour. This list named the printers by brand. The user clicked on a printer from the list, and that was the end of it. The user certainly never saw Canon_PIXMA_900.local in any UI. I'm fairly sure this is true of Linux as well. Apparently multicast DNS works even in the absence of mental models. It works in the sense that if you know the name of the machine you are trying, and tack .local on the end, there is a small chance that you will get to that machine. But usually you won't, because various network glitches will have caused the machine to rename itself to machine-04.local by the time you try to address it, even though there were never any machine.locals other than that one. mDNS is a nice hack, but fairly useless for the particular application we are talking about. It's pretty good for service discovery (showing a list of printers in a UI). IMHO, we shouldn't promote bad solutions, and .local is a bad solution. A bad solution to what problem? Well, indeed. We are clearly talking about different problems. Several people spoke in favor of supporting existing solutions (a.k.a. running code). I'd like to see us gauge consensus for this point here on the list. I'm against it, as you know. The problem with the current running code is that namespaces overlap, and the UI has no way to detect or present this. Settling on a half solution because we have running code is the wrong way to go. I tried to show in the print server example that the client may cache unique information about the server (GUID, unique host name, etc.) that makes disambiguation a non-issue. But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know which fridge is the right one. (I'm just repeating Stuart Cheshire here, from a conversation we had last week). So the GUID doesn't give us the information we want, and indeed can produce confusing results in the UI. A per-site naming scheme, with a nice UI on top of it, _does_ give us that. Fridge can be fridge (home) and fridge (here) in the UI, for instance, because we know we aren't at home. It was agreed that name-random.local. is equivalent to name.local-random. from a CS standpoint. Here you are definitely arguing about the wrong problem. At the presentation layer, both are equivalent, and both are wrong. What we want is not fridge-1.local and fridge-2.local, but fridge (here) and fridge (there). - it is relatively easy to retrofit this behavior to hosts and servers and difficult (or impossible) to reflash existing printers You don't need to update the printers. Just have the CPE device say where you are. This stuff can all happen at the presentation layer—at the protocol layer, it's perfectly fine if the printer is printer.local as long as the CPE says what local means, and the UI presents it correctly. - using .local-random. based on ULA means complexity equivalent to ULA distribution problem. This is a big issue when homenets are coalesced and can't be solved by routing alone. In general, the homenet merge is not likely to be a homenet merge in the sense you mean, but rather a decommissioning of one of two routers, and a migration of the devices formerly connected to the one router to the network operated by the other router. In this case, a CPE-advertised location will solve the problem in a nice, intuitive way—all the devices will appear in the UI as being connected to the local network. I think you're referring to a _different_ problem; resolving your site's resources while you are mobile. Am I mistaken? I'm claiming that this isn't a separate problem. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Mon, Aug 6, 2012 at 8:18 AM, Ted Lemon mel...@fugue.com wrote: On Aug 6, 2012, at 12:58 AM, Kerry Lynn wrote: Domains like .local seem like a good idea to geeks like us, but how many regular users ever use them? Every single user who has added a printer to OS X or Linux in the last several years. No. You think that because you're a geek like the rest of us. I think there may be two kinds of geeks on this list, those who want to take corporate networks and scale them down for home users and those who want to extend existing home networks and make them more functional. These two points of view may lead to a common solution for any given problem, but that's not yet evident. Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour. This list named the printers by brand. The user clicked on a printer from the list, and that was the end of it. The user certainly never saw Canon_PIXMA_900.local in any UI. I'm fairly sure this is true of Linux as well. Sorry, not sure I'm getting your point. Yes, the user is using a UI to solve her problem. The UI in this case is using (multicast) DNS. DNS requires a zone to scope the query. That zone is .local.. My car probably has 15 microcontrollers and I use them when I drive to the market whether I'm aware of it (which I don't want to be) or not. What appears in my list is a _default_ SRV record name consisting of the printer model plus gibberish (in my case Office Jet Pro A909g [4C0EA4]). The gibberish is the least significant 24-bits of the MAC address (printed on the box, on a sticker near the network port, on the test page that ejects from the printer, and from the setup menu on the printer's screen. The user is given the chance to change the name when the printer is added; thereafter it is only slightly more complicated to change it. Another advantage to adding gibberish to the SRV name (aside from those I listed earlier) is that it reduces the probability of name conflicts. There can be many sources for this gibberish, but it is relatively easy to use some intrinsic identifier. The hack above is slightly worse than a five-digit zip code, slightly better than a nine-digit zip code - the point being that users already deal with a certain amount of gibberish in their lives. Apparently multicast DNS works even in the absence of mental models. It works in the sense that if you know the name of the machine you are trying, and tack .local on the end, there is a small chance that you will get to that machine. But usually you won't, because various network glitches will have caused the machine to rename itself to machine-04.local by the time you try to address it, even though there were never any machine.locals other than that one. Hard for me to buy this, unless the device is hearing from itself via tape delay. mDNS is a nice hack, but fairly useless for the particular application we are talking about. It's pretty good for service discovery (showing a list of printers in a UI). IMHO, we shouldn't promote bad solutions, and .local is a bad solution. A bad solution to what problem? Well, indeed. We are clearly talking about different problems. Yes, there are at least two problems: how to disambiguate name collisions in locally served zones and how to access remote resources. We agree that these problems collapse if you outlaw locally served zones. We disagree on the utility and/or reliability of locally served zones. This is why I'm pushing back and saying the problems you raise with mDNS are solvable. I think that in the short run it is easier to connect users to their existing networks (e.g. through tunnels) than it is to educate them on the workings of DNS and require them to deploy a global zone before they can connect to any device. Several people spoke in favor of supporting existing solutions (a.k.a. running code). I'd like to see us gauge consensus for this point here on the list. I'm against it, as you know. The problem with the current running code is that namespaces overlap, and the UI has no way to detect or present this. Settling on a half solution because we have running code is the wrong way to go. I tried to show in the print server example that the client may cache unique information about the server (GUID, unique host name, etc.) that makes disambiguation a non-issue. But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know which fridge is the right one. (I'm just repeating Stuart Cheshire here, from a conversation we had last week). So the GUID doesn't give us the information we want, and indeed can produce confusing results in the UI. A per-site naming scheme, with a nice UI on top of it, _does_ give us that. Fridge can be fridge (home) and fridge (here) in the UI, for instance, because we know we aren't at home. And I'm saying it can just as
Re: [homenet] tunnels as way to disambiguate .local
On 08/06/2012 07:17 AM, Ted Lemon wrote: Every single user who has added a printer to OS X or Linux in the last several years. No. You think that because you're a geek like the rest of us. Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour. This list named the printers by brand. The user clicked on a printer from the list, and that was the end of it. The user certainly never saw Canon_PIXMA_900.local in any UI. I'm fairly sure this is true of Linux as well. Speaking as a geek who not only remembers NBP but actually wrote an implementation of it, I have to say that it never even occurred to me that there is some sort of IP equivalent of NBP. It just doesn't fit the same mental model as fqdn's which is how I and just about everybody else thinks of net naming. In fact, I'm being far too generous with fqdn's. People don't even think about them other than maybe top level brand names.com. Nowadays, people expect to just search for whatever's relevant. If it doesn't come up in search, it must not exist. I have to say that part of my struggle here is just understanding the problem(s) coming in from the cold. I see lots of hammers being applied to things that may or may not resemble nails, but much less about the real world aspects of this problem, cf search above. Mike Apparently multicast DNS works even in the absence of mental models. It works in the sense that if you know the name of the machine you are trying, and tack .local on the end, there is a small chance that you will get to that machine. But usually you won't, because various network glitches will have caused the machine to rename itself to machine-04.local by the time you try to address it, even though there were never any machine.locals other than that one. mDNS is a nice hack, but fairly useless for the particular application we are talking about. It's pretty good for service discovery (showing a list of printers in a UI). IMHO, we shouldn't promote bad solutions, and .local is a bad solution. A bad solution to what problem? Well, indeed. We are clearly talking about different problems. Several people spoke in favor of supporting existing solutions (a.k.a. running code). I'd like to see us gauge consensus for this point here on the list. I'm against it, as you know. The problem with the current running code is that namespaces overlap, and the UI has no way to detect or present this. Settling on a half solution because we have running code is the wrong way to go. I tried to show in the print server example that the client may cache unique information about the server (GUID, unique host name, etc.) that makes disambiguation a non-issue. But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know which fridge is the right one. (I'm just repeating Stuart Cheshire here, from a conversation we had last week). So the GUID doesn't give us the information we want, and indeed can produce confusing results in the UI. A per-site naming scheme, with a nice UI on top of it, _does_ give us that. Fridge can be fridge (home) and fridge (here) in the UI, for instance, because we know we aren't at home. It was agreed that name-random.local. is equivalent to name.local-random. from a CS standpoint. Here you are definitely arguing about the wrong problem. At the presentation layer, both are equivalent, and both are wrong. What we want is not fridge-1.local and fridge-2.local, but fridge (here) and fridge (there). - it is relatively easy to retrofit this behavior to hosts and servers and difficult (or impossible) to reflash existing printers You don't need to update the printers. Just have the CPE device say where you are. This stuff can all happen at the presentation layer—at the protocol layer, it's perfectly fine if the printer is printer.local as long as the CPE says what local means, and the UI presents it correctly. - using .local-random. based on ULA means complexity equivalent to ULA distribution problem. This is a big issue when homenets are coalesced and can't be solved by routing alone. In general, the homenet merge is not likely to be a homenet merge in the sense you mean, but rather a decommissioning of one of two routers, and a migration of the devices formerly connected to the one router to the network operated by the other router. In this case, a CPE-advertised location will solve the problem in a nice, intuitive way—all the devices will appear in the UI as being connected to the local network. I think you're referring to a _different_ problem; resolving your site's resources while you are mobile. Am I mistaken? I'm claiming that this isn't a separate problem. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet
Re: [homenet] tunnels as way to disambiguate .local
On Mon, Aug 06, 2012 at 10:17:34AM -0400, Ted Lemon wrote: Here you are definitely arguing about the wrong problem. At the presentation layer, both are equivalent, and both are wrong. What we want is not fridge-1.local and fridge-2.local, but fridge (here) and fridge (there). If you want access to fridge (there), then fridge (there) has to have a globally-addressable domain name. If it doesn't have one, then there's no way for you to reach it, and I can't think of any reason for a well-designed UI to display it. If fridge.local is available, then it must be fridge (here). As I see it, those who have devices that they wish to reach remotely will have to either own their own domain names, or acquire delegated subdomains from e.g. their ISP or their hardware vendor (I could see Apple including one in the price of an Airport Express, for example). If your network is configured with such a name, and if you have a printer configured to allow remote access, then the name it advertises and which your UI will cache will be something like printer-2.my-personal-domain.com or printer-3.smithfamily1137.mac.com. I think we have general consensus in the WG that this is a good approach for remote access. So now we're just talking about people who *don't* choose to have their devices remotely accessible; those people's devices would use non-globally- addressable names. Now (as I understand it) the primary advantage to using .ULA or .ULA.local naming is the ability to cache separate lists of discovered devices for different networks that you happen to visit. That is, if I'm visiting Ted's house, I'd like to see the list of devices I've previously found on Ted's network, and if I'm at home, I'd like to see the list of devices on mine. But I don't see a requirement for a network name to be globally unique if it isn't globally addressable. I could simply *choose* a name to disambiguate my network from Ted's, just as most of us choose our own SSIDs. You'd want to choose one unique enough that you wouldn't run into duplicates very frequently, but that would be at most a recommendation, not a requirement. So let's say my house uses names in the evanshouse.local namespace. For most visitors, this is sufficient to separate things out. If a visitor happens to have the same network name as I do, then my devices and theirs could get mixed up in their lists of cached names, and that's suboptimal and inconvenient, but not (as far as I can see) particularly harmful. If I buy a new router, it will ask me what network name to use, and I will easily remember that I've been using evanshouse. There's no need to look up the hexadecimal gibberish supplied by my previous router. If I absolutely refuse to give my router a network name, then it could choose one for me, and in that event a ULA-style name seems like a good choice. But I would expect it to be a rare one. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
The problem is that you are assuming (a) that only geeks will ever want remotely-addressable networks (and hence, we don't need to specify a mechanism for automatically setting that up, because they can do it manually), and (b) that no network will ever go from being locally-addressed to globally-addressed. Both of these are self-fulfilling prophecies that I would like to prevent fulfilling themselves. Oh, and (c) that a person with a local-only homenet will never take their laptop or cell phone to someone else's house where a naming scheme conflict happens to exist, and accidentally tweak something because of the clash. Global naming implies state, among other things. mDNS is sort of stateless, except of course that it's not completely stateless, and breaks badly in some cases when you treat it as if it is. So state is, IMHO, a better solution even in the local-only situation, because you're owning the fact that you have state, and you have to go to the trouble to get it right. And it has a clean upgrade path to the local/remote situation. And it doesn't surprise anyone with naming clashes when visiting the neighbors' network. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Mon, Aug 06, 2012 at 02:51:48PM -0400, Ted Lemon wrote: The problem is that you are assuming (a) that only geeks will ever want remotely-addressable networks (and hence, we don't need to specify a mechanism for automatically setting that up, because they can do it manually), Not at all -- lots of non-geeks buy domain names, and non-geeks can also get delegated subdomains from their ISP's. Making it easy for them to set up is a UI problem, and not a very hard one. You can't use .ULA to reach a remote device anyway. and (b) that no network will ever go from being locally-addressed to globally-addressed. Not really. If you acquire a globally-resolvable domain name, then your printer could detect the fact and start advertising the name printername.domain.com alongside printername.myhouse.local; your laptop could then cache the new name, note that it's a FQDN, and begin showing it to you in a list of available printers when you're away from home. Oh, and (c) that a person with a local-only homenet will never take their laptop or cell phone to someone else's house where a naming scheme conflict happens to exist, and accidentally tweak something because of the clash. I think this concern is fairly minimal, and could be addressed by noting that the router MAC address has changed and popping up a warning dialog. breaks badly in some cases when you treat it as if it is. So state is, IMHO, a better solution even in the local-only situation, because you're owning the fact that you have state, and you have to go to the trouble to get it right. Explain what you mean by state here please? I'm not sure I'm following you. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Aug 6, 2012, at 5:44 PM, Evan Hunt wrote: Not at all -- lots of non-geeks buy domain names, and non-geeks can also get delegated subdomains from their ISP's. Making it easy for them to set up is a UI problem, and not a very hard one. You can't use .ULA to reach a remote device anyway. We're talking past each other. I am not saying that .ULA is the right solution. And as far as it being a UI problem, this is half true. If the underlying protocol can set things up cleanly and reliably and automatically, *then* getting the UI right is a UI problem. But if the underlying protocol doesn't allow a UI that a regular user can navigate, it doesn't matter how good the UI is. Not really. If you acquire a globally-resolvable domain name, then your printer could detect the fact and start advertising the name printername.domain.com alongside printername.myhouse.local; your laptop could then cache the new name, note that it's a FQDN, and begin showing it to you in a list of available printers when you're away from home. Requiring the printer and host to adapt to network conditions in the way you describe is not a homenet issue except in the sense that the homenet would have to present the information to the host or printer to allow it to do what you describe. Which is precisely what (I thought) we were discussing. I think this concern is fairly minimal, and could be addressed by noting that the router MAC address has changed and popping up a warning dialog. You are talking about this as if you were the programmer. But we are the IETF, not the UI programmer. It's not our job to get the UI right—it's to make it *possible* to get the UI right. Explain what you mean by state here please? I'm not sure I'm following you. State is stuff that either your host or some server remembers between packet exchanges. So for example, your laptop probably remembers its own name, and provides it using mDNS and DHCP. That's state. If the DHCP server records it in the DNS, that's also state. No state is when nothing is recorded anywhere. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Mon, Aug 06, 2012 at 04:33:49PM -0400, Michael Richardson wrote: No, the fridge must have a globally reachable address (GUA) to be reachable. You are correct, of course, and I was being unclear; sorry about that. I was trying to reflect what I thought I heard in the discussion in Vancouver, though, which was that a FQDN or the equivalent would be the best way to handle naming of remotely accessible devices. It seemed to me that we had rough consensus on that point (perhaps I was mistaken), but not on naming of devices on island networks. Tunnels are okay, but to use them, but has to get the DNS search order and the DNS server list right, and that's walled garden territory. *If* we are going to turn each home into a walled garden, then let's be aware that we are doing that. For the purposes of my mom's house, I do think walled garden is the appropriate default setting, but our design should allow the default to be overridden without great difficulty. I think this general plan would meet those goals: 1) All discoverable devices on all networks MUST answer to a locally reachable name, such as devicename.local, devicename.sitelocal, devicename.networkname.local, devicename.ULA, devicename-ULA.local, etc. (We haven't settled the naming convention here. I personally like devicename.networkname.local, with devicename.ULA.local as a fallback in the event of the network's owner failing to configure a network name); 2) Networks configured to allow remote access to devices SHOULD have a globally reachable domain name, either owned by the user or in a vendor-managed namespace; 3) If a device is configured for remote access and is on a network which has had a FQDN configured as in (2), then in addition to the locally reachable name described in (1), the device MUST also answer to devicename.FQDN. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
3) If a device is configured for remote access and is on a network which has had a FQDN configured as in (2), then in addition to the locally reachable name described in (1), the device MUST also answer to devicename.FQDN. And, I'm not sure these are within the scope of homenet, but to explicitly state the design principles I'm trying to support with the previous recommendations: - Applications wanting to cache information about discovered devices should use the most globally-reachable name available for each device. In other words, if it has a FQDN and a local-only name, cache the FQDN. - When presenting cached information about devices, applications should only display local-only domain names if they were cached from the current local network. - When possible, preference should be given to the use of human-readable, human-memorable, and ideally human-selected names. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. I'm talking about using the ULA to generate a HomenetID for use in the namespace. See RFC6281. The HomenetID and DNS subomain (or as you put it somethingveryobscure) may be generated by one unique host (e.g. each Homenet border router) based on a ULA. But that does not mean it cannot be discovered by all hosts and routers in the Homenet (via some bunch of discovery mechanisms such as automatic prefix distribution for router-router and DHCPv6 for router - fridge). The HomenetID will remain constant as long as the ULA of the border router remains constant. If it appears to vary (because the border router changes) then highly mobile nodes will get some indication that they may not be connected to their own Homenet, and ask for user input to accept an update. Static nodes would only know their local HomenetID, and if it changed they could be set to always accept the update without user input. Eventually you would probably end up with a search list linked to the number of border routers the end node has ever encountered, but end nodes can automatically age out old entries. We might also want to be able to manually override the auto-generated HomenetID to cover the case where border router hardware is replaced by the user, but that's no different to MAC address cloning on CPE's in the past (where ISPs used the MAC address of the CPE as an identifier in management systems). Sure there's a downside in complexity of the namespace. The potential upside of this approach is that the same somethingveryobscure.sitelocal. zone file could also be mounted as a secondary on somethingveryobscure .ISP DNS root or somethingveryobscure .employer's DNS root if the ISP or enterprise wished to provide this service for global name resolution. Highly mobile nodes would only need two items in their DNS search list, the search list can be pretty much auto-generated, and they can use the same name resolution technology (DNS) wherever they are located. It also completely avoids trying to synch mDNS with DNS, which I think you'll agree is likely to be very difficult. Curtis Villamizar mailto:cur...@occnc.com 4 August 2012 22:06 With all due respect, any suggestion to use the ULA in a domain name produces either a domain that is unique to one host or a domain that is every bit as global as sitelocal, depending on whether by stating ULA prefix you mean the local ULA or the well-known global ULA prefix. In rfc4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. [...] If you mean the first (the local ULA prefix), then the domain is unique to one host. My computer could never find my fridge using the hostname fridge unless it knew every ULA on the local network and created an entry in the dns search path. Very long entries in the dns search path are a very bad thing (tm). If you means the second (the assigned prefix under which all ULA fall) then the domain is common to all hosts in the universe that generate a ULA address. The only difference is it is host.somethingveryobscure.sitelocal. Curtis In message 501965d4.1040...@globis.net ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On 05/08/2012 07:58, Ray Hunter wrote: I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. That's what I meant too. The only point is to avoid ambiguity in the namespace. The only reason for using a ULA prefix to create a unique identifier string is to avoid the bother of inventing a new method of creating a unique identifier string. The name has no relation to addressing or routing whatever. If you prefer some other way of creating a string with a very high probability of uniqueness, that's fine. Brian I'm talking about using the ULA to generate a HomenetID for use in the namespace. See RFC6281. The HomenetID and DNS subomain (or as you put it somethingveryobscure) may be generated by one unique host (e.g. each Homenet border router) based on a ULA. But that does not mean it cannot be discovered by all hosts and routers in the Homenet (via some bunch of discovery mechanisms such as automatic prefix distribution for router-router and DHCPv6 for router - fridge). The HomenetID will remain constant as long as the ULA of the border router remains constant. If it appears to vary (because the border router changes) then highly mobile nodes will get some indication that they may not be connected to their own Homenet, and ask for user input to accept an update. Static nodes would only know their local HomenetID, and if it changed they could be set to always accept the update without user input. Eventually you would probably end up with a search list linked to the number of border routers the end node has ever encountered, but end nodes can automatically age out old entries. We might also want to be able to manually override the auto-generated HomenetID to cover the case where border router hardware is replaced by the user, but that's no different to MAC address cloning on CPE's in the past (where ISPs used the MAC address of the CPE as an identifier in management systems). Sure there's a downside in complexity of the namespace. The potential upside of this approach is that the same somethingveryobscure.sitelocal. zone file could also be mounted as a secondary on somethingveryobscure .ISP DNS root or somethingveryobscure .employer's DNS root if the ISP or enterprise wished to provide this service for global name resolution. Highly mobile nodes would only need two items in their DNS search list, the search list can be pretty much auto-generated, and they can use the same name resolution technology (DNS) wherever they are located. It also completely avoids trying to synch mDNS with DNS, which I think you'll agree is likely to be very difficult. Curtis Villamizar mailto:cur...@occnc.com 4 August 2012 22:06 With all due respect, any suggestion to use the ULA in a domain name produces either a domain that is unique to one host or a domain that is every bit as global as sitelocal, depending on whether by stating ULA prefix you mean the local ULA or the well-known global ULA prefix. In rfc4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. [...] If you mean the first (the local ULA prefix), then the domain is unique to one host. My computer could never find my fridge using the hostname fridge unless it knew every ULA on the local network and created an entry in the dns search path. Very long entries in the dns search path are a very bad thing (tm). If you means the second (the assigned prefix under which all ULA fall) then the domain is common to all hosts in the universe that generate a ULA address. The only difference is it is host.somethingveryobscure.sitelocal. Curtis In message 501965d4.1040...@globis.net ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Brian E Carpenter wrote: On 05/08/2012 07:58, Ray Hunter wrote: I disagree. The context of my message is that there should be some identifier that can disambiguate the namespace per Homenet. That's what I meant too. The only point is to avoid ambiguity in the namespace. The only reason for using a ULA prefix to create a unique identifier string is to avoid the bother of inventing a new method of creating a unique identifier string. The name has no relation to addressing or routing whatever. If you prefer some other way of creating a string with a very high probability of uniqueness, that's fine. So I think I understand the point of a ULA like suffix. However, that doesn't translate into a name that anybody would use. Locally, you could just have it as part of the DNS search list, I suppose, but that's limited to resources that are accessed locally which .local more or less works now. So it seems a small gain with some ugliness to boot. What I really want though is to have resources that I can access regardless of where I am though. I don't see how this is of any help at all for that problem. The only thing I see is that either I make the name globally accessible -- in which case I'd use a real DNS name, or to make myself topologically part of the .local[site] namespace. Isn't that what this all boils down to? TANSTAAFL? Mike PS: the 40 bits of a ULA was constrained by v6 prefix length. if we were to do this for sitelocal, we'd probably want to add some bits to better cope with the birthday paradox. iirc, 64 bits is a lot safer. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. The apparent consensus in Vancouver was to use a global domain if you have one available I agree there was consensus on this point. otherwise use an auto-generated unique local domain. ...but I did not hear a clear consensus on this one. (For the record, though I'm open to being convinced otherwise, my current preference is for a reserved generic namespace such as .local and/or .sitelocal, and *not* for ULA-style domains.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Aug 5, 2012, at 10:06 PM, Evan Hunt wrote: (For the record, though I'm open to being convinced otherwise, my current preference is for a reserved generic namespace such as .local and/or .sitelocal, and *not* for ULA-style domains.) i wasn't able to participate in this discussion because I had other business during homenet, but I'm a bit frustrated by this conclusion. Domains like .local seem like a good idea to geeks like us, but how many regular users ever use them? How many have a mental model of how naming works that would allow these domains to function for them? IMHO, we shouldn't promote bad solutions, and .local is a bad solution. Whether we come up with some way to leverage a ULA to present things sensibly in some UI is another question, but if we are trying to come up with a solution for geeks, why not come up with a _real_ solution, instead of the .local hack? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
i wasn't able to participate in this discussion because I had other business during homenet, but I'm a bit frustrated by this conclusion. I was speaking for myself and I believe the issue is in flux; please don't take it as a conclusion. :) IMHO, we shouldn't promote bad solutions, and .local is a bad solution. IMHO .hexidecimal-gibberish is also a bad solution. It's, at least potentially, a worse one: you buy a new router, and suddenly your devices all have new names and your bookmarks don't work. To make them work again, you have to remember the hexidecimal-gibberish that was assigned by your previous router and configure it to use the same one. Ugly. I'm not really happy with either of these choices, but I'm less unhappy with .sitelocal. Whether we come up with some way to leverage a ULA to present things sensibly in some UI is another question, but if we are trying to come up with a solution for geeks, why not come up with a _real_ solution, instead of the .local hack? I'd love to hear the plan. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
With all due respect, any suggestion to use the ULA in a domain name produces either a domain that is unique to one host or a domain that is every bit as global as sitelocal, depending on whether by stating ULA prefix you mean the local ULA or the well-known global ULA prefix. In rfc4193: Local IPv6 unicast addresses have the following characteristics: - Globally unique prefix (with high probability of uniqueness). - Well-known prefix to allow for easy filtering at site boundaries. [...] If you mean the first (the local ULA prefix), then the domain is unique to one host. My computer could never find my fridge using the hostname fridge unless it knew every ULA on the local network and created an entry in the dns search path. Very long entries in the dns search path are a very bad thing (tm). If you means the second (the assigned prefix under which all ULA fall) then the domain is common to all hosts in the universe that generate a ULA address. The only difference is it is host.somethingveryobscure.sitelocal. Curtis In message 501965d4.1040...@globis.net Ray Hunter writes: Isn't it possible to combine the two ideas of sitelocal. with pseudo-domains generated from ULA to give a usable solution? e.g. fridge.pseudo-ula-domain.sitelocal. Don't you then avoid the evilness of identifier overloading (my fridge versus your fridge) and potential problems with clashing TLD's? e.g. someone registering a bunch of pseudo-ula-domain. TLD records as their company brand for manual administration. How else are homenet devices going to know not to bother the root servers with fridge.pseudo-ula-domain. NS queries given that TLD's are now basically a free for all? Wouldn't it also potentially give a unique anchor point for storing DNSSEC zone signing with an implicit sitelocal. trust anchor? regards, RayH Brian E Carpenter wrote: Synthesise a pseudo-TLD from the ULA prefix. Brian Brian E Carpenter wrote: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Brian == Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian Correct, but the name is unambiguous, which IMHO is a MUST Brian property for anything that looks like an FQDN. We have to Brian live with .local but it should be just a nasty memory like Brian 10.0.0.0/8 fifty years from now. Brian I would suggest instructing IANA to reserve all TLD strings Brian that start with local and using something like Brian .local-fd952a92a67d to name the homenet domain. It's only a Brian convenience to use a ULA prefix; it's simply a unique string Brian that the CPE needs to generate anyway, but it has no Brian significance beyond that. huh, you want to do it that way? Why not fd952a92a67d.local? I'm asking for clarification, not disagreeing. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgp0136eDouIj.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Wed, Aug 1, 2012 at 3:17 PM, Evan Hunt e...@isc.org wrote: Do we want applications caching mDNS replies into configuration files? I think not, and I think the DNS people will shout loudly about that. Hm... I'm a DNS people, but I'm not sure I object to this. You'd want some mechanism for clearing old records out after the devices had been gone from the network for a long-enough time, but that's not intrinsically hard. Printing is an example, but this could apply to other apps as well (it's just that there are already millions of deployed mDNS printers about). One thing to keep in mind is that it is easier to modify the end hosts (OS providers regularly push updates) and print servers than the printers themselves. The idea assumes you need to be on-site to discover and add the printer in the first place (establishing some level of trust in the process). The mDNS draft enforces this by filtering out a) multicast discovery responses that don't have a link-local multicast destination address, or b) unicast responses that don't have the same source prefix as the querier. CUPS (and I presume other print systems) already cache a great deal of info about my printer and additionally caching a GUA if it was advertised does not seem a reach. Here's an example from my /etc/cups/printers.conf: Printer Officejet_Pro_8500_A909g UUID urn:uuid:dbb55a90-16ba-3534-5c4a-6da0e0d327a1 Info Officejet Pro 8500 A909g MakeModel HP Officejet Pro 8500 A909g Series DeviceURI dnssd://Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D._pdl-datastream._tcp.local./?bidi ... /Printer Here you see the service instance name Officejet Pro 8500 A909g which appears in my print dialog, together with other unique info that prevents it from being confused with yours, if you had one and I was visiting. If, at service discovery time, my printer had advertised a GUA then I'm suggesting it could have been cached as well. In that case, the print system would formulate a *unicast* DNS query to that GUA for a RR named Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D. If a response is returned, that strongly implies the printer is reachable and no resolution is necessary (this would also solve the problem I currently have with printing to other LAN segments). If that query *fails* then indicates I need to do a fresh resolution. Here's where Michael's idea to advertise a FQDN binding (which can also be cached) comes in. But first... ** TERMINOLOGY ALERT ** I suggest we reserve the term FQDN to refer to names that have been fully qualified in the global DNS namespace (as they all probably were when the term was first coined) and use something like LQDN to refer to names that are qualified in a locally-served (non-delegated) DNS zone. ...so by FQDN I mean that the original mDNS query return something like foo.local. CNAME foo.example.com. (Yes, I realize we may need to invent some new RR to express the LQDN-to-FQDN mapping). I regularly print to both my work and home printer remotely (yes, over IPv6. The CUPS server speaks IPv6 even if my home printer speaks only USB). I'm of the opinion that remote access from offsite should be a service you can configure your printer to provide, but which is not the default. I think this is part and parcel of advertising the GUA and/or LQDN-to-FQDN mapping, as above, or not, under control of the user. Alternately, this functionality could be deployed in a print server which just connects via USB to the printer. Such a server could be tightly coupled to the client functionality and provide mutual authentication, privacy, etc. Of course, you get all these things if you just tunnel back to your site in the first place ;-) In my ideal world (please indulge me in a moment of handwaving), you plug in your printer, and tell it what its name is (or let it pick its own default such as LaserPrinter-3); it announces itself to the local network as providing local printing, and its name is placed in the .sitelocal domain. *If* you check the box for let the outside world print to me -- which you and I might want to do but most people wouldn't -- then it announces itself as providing both local and remote printing, and its name is placed in .sitelocal and then mirrored into the globally addressable domain that you'd previously configured for your network: by preference, that would be your private domain name, but if you don't have one of those then it could mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever. If you were printing something, and you a found a printer via service discovery which indicate that it could provide remote access, then you'd be given the option to bookmark its global name and use it when you're away; if it isn't configured for remote access then you woulnd't be given that option. A similar mental model could apply to the fridge and lamp examples we've been kicking around as well -- you won't normally *want* them to be
Re: [homenet] tunnels as way to disambiguate .local
On Wed, Aug 1, 2012 at 1:22 PM, Ray Hunter v6...@globis.net wrote: Isn't it possible to combine the two ideas of sitelocal. with pseudo-domains generated from ULA to give a usable solution? e.g. fridge.pseudo-ula-domain.**sitelocal. Two points. As I mentioned at the mic yesterday, this maps onto the ULA distribution problem. You'd either have to identify a deterministic root ULA for this zone or guarantee that multiple such zones within a given site all appear as being on-site. Second, is the unique string part of the name or a zone of the domain? mDNS recommends that all host names in .local. appear as a flat namespace, but this is only a recommendation. We humans started using surnames some time ago to disambiguate our identities regardless of location (although I note that many such attempts were of the form O'There). Don't you then avoid the evilness of identifier overloading (my fridge versus your fridge) and potential problems with clashing TLD's? e.g. someone registering a bunch of pseudo-ula-domain. TLD records as their company brand for manual administration. How else are homenet devices going to know not to bother the root servers with fridge.pseudo-ula-domain. NS queries given that TLD's are now basically a free for all? I think this is a darned good point. It saves every resolver from having to parse .local-mumble. to decide whether it should delegate or not. Wouldn't it also potentially give a unique anchor point for storing DNSSEC zone signing with an implicit sitelocal. trust anchor? An even better point. -K- regards, RayH Brian E Carpenter wrote: Synthesise a pseudo-TLD from the ULA prefix. Brian Brian E Carpenter wrote: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian __**_ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/**listinfo/homenethttps://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On Wed, Aug 1, 2012 at 2:09 PM, Michael Richardson mcr+i...@sandelman.cawrote: snip Kerry BTW, I agree with the earlier comment that the may be several Kerry good reasons to include VPN tunnels in the homenet Kerry architecture. They exist. It would be nice if our secure setup protocol for homenet could also be leveraged to setup remote access. The VLAN service access point may be the only thing I (and perhaps many others) would ever want to advertise in the global DNS namespace. -K- -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Synthesise a pseudo-TLD from the ULA prefix. Brian On 01/08/2012 15:17, Curtis Villamizar wrote: In message 5018d80c.90...@gmail.com Brian E Carpenter writes: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian Brian, Not being connected to the Internet and not having any configuration at all might also be intrinsically evil, but that's the situation when a consumer takes some gadget out of the box. What we are trying to accomplish with the sitelocal is a way to name things on a local network that have no domain name assigned through a registry and have not had a domain name assigned as part of some subdomain of the provider. Even if the homenet WG was extremely thoroughthe gadget did 100% of what we specify and implemented everything perfectly, we can't control the user who almost never has a domain name of their own or the ISP that can't be bothered delegating some subdomain of theirs to a customer. The customer then has no global domain to hang names off of and has no choice but to not use DNS or make use of a sitelocal domain with site local scope. So sitelocal is inherently needed, either during a transition (until the uplink comes up at least for the first time and a domain name is learned) or permanently (if no domain name ever gets delegated to the residential customer site). Curtis ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. But we can't control those MSO and ILEC residential ISPs. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
On 08/01/2012 12:17 AM, Brian E Carpenter wrote: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. I think the implications of my note is that there really isn't anything that needs to be done here. If you want to use naming that requires that you be in some topology-defined boundary, then tunnel back to that network if you're not there. VPN technology is pretty well understood, after all, and there are probably a lot of reasons you might want to do that besides naming. That said, my interpretation of the requirements is that we want to do something with names such that they are quasi-global, or truly global. I'm inclined to agree that grafting those requirement onto .local is most likely the road to madness. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Brian == Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian And therefore intrinsically evil, just like 10.0.0.0/8 is Brian intrinsically evil. Brian IMHO we shouldn't be discussing how to make it work less Brian badly; we should be discussing how to avoid it entirely. Right, but we have installed base. Based upon comments in Jabber yesterday, I think that the right way is for fridge.local mDNS to return a series of SRV records in the additional information, one of which would contain a FQDN (having a GUA) for the fridge, if it had one. I don't know exactly what that would look like, but it seems like the right process: discovery gives us a name, and the name is sometimes a FQDN. That would also have solved Stuart's problem printing to bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather than bluehawaii.local (nothing that bluehawaii.apple.com works just fine when in the office) -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpHS6xmlUqaH.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Isn't it possible to combine the two ideas of sitelocal. with pseudo-domains generated from ULA to give a usable solution? e.g. fridge.pseudo-ula-domain.sitelocal. Don't you then avoid the evilness of identifier overloading (my fridge versus your fridge) and potential problems with clashing TLD's? e.g. someone registering a bunch of pseudo-ula-domain. TLD records as their company brand for manual administration. How else are homenet devices going to know not to bother the root servers with fridge.pseudo-ula-domain. NS queries given that TLD's are now basically a free for all? Wouldn't it also potentially give a unique anchor point for storing DNSSEC zone signing with an implicit sitelocal. trust anchor? regards, RayH Brian E Carpenter wrote: Synthesise a pseudo-TLD from the ULA prefix. Brian Brian E Carpenter wrote: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 50193cab.5070...@gmail.com Brian E Carpenter writes: Synthesise a pseudo-TLD from the ULA prefix. Brian If the whole ULA is used, then the scope is single host. If the ULA prefix is used, then the scope is all reachable ULA which is the same as sitelocal but with an obscure name. Curtis On 01/08/2012 15:17, Curtis Villamizar wrote: In message 5018d80c.90...@gmail.com Brian E Carpenter writes: On 01/08/2012 05:48, Curtis Villamizar wrote: ... fridge.sitelocal. is a FQDN with site local scope. And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil. IMHO we shouldn't be discussing how to make it work less badly; we should be discussing how to avoid it entirely. Brian Brian, Not being connected to the Internet and not having any configuration at all might also be intrinsically evil, but that's the situation when a consumer takes some gadget out of the box. What we are trying to accomplish with the sitelocal is a way to name things on a local network that have no domain name assigned through a registry and have not had a domain name assigned as part of some subdomain of the provider. Even if the homenet WG was extremely thoroughthe gadget did 100% of what we specify and implemented everything perfectly, we can't control the user who almost never has a domain name of their own or the ISP that can't be bothered delegating some subdomain of theirs to a customer. The customer then has no global domain to hang names off of and has no choice but to not use DNS or make use of a sitelocal domain with site local scope. So sitelocal is inherently needed, either during a transition (until the uplink comes up at least for the first time and a domain name is learned) or permanently (if no domain name ever gets delegated to the residential customer site). Curtis ps - Yes - it is inherently evil. So is not delegating rDNS IMHO. But we can't control those MSO and ILEC residential ISPs. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Kerry == Kerry Lynn kerlyn2...@gmail.com writes: Kerry Actually, I think the problem may be that CUPS insists on Kerry re-resolving the name every time it prints, rather than Kerry trying the GUA that it would have learned at initial Kerry discovery. Do we want applications caching mDNS replies into configuration files? I think not, and I think the DNS people will shout loudly about that. Kerry Nobody seems to be complaining about the need to be on-site Kerry to discover the service initially. The issues seem to be No, in fact, it's a feature. Kerry my desk, unless I connect my host to that same link. I Kerry cannot remember a time when I needed to use it remotely. I regularly print to both my work and home printer remotely (yes, over IPv6. The CUPS server speaks IPv6 even if my home printer speaks only USB). I do this will all sorts of paperwork, receipts for online expenses, etc. Yes, I sometimes print to the wrong printer. I also regularly print to these printers when offline, knowing that CUPS will punt it out when I get home I believe that Google Cloud Print is getting close to eliminating my need to own one of these infernal mechanical devices. Kerry BTW, I agree with the earlier comment that the may be several Kerry good reasons to include VPN tunnels in the homenet Kerry architecture. They exist. It would be nice if our secure setup protocol for homenet could also be leveraged to setup remote access. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpIVl0bSseGL.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 17002.1343839...@obiwan.sandelman.ca Michael Richardson writes: Brian =3D=3D Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian And therefore intrinsically evil, just like 10.0.0.0/8 is Brian intrinsically evil. Brian IMHO we shouldn't be discussing how to make it work less Brian badly; we should be discussing how to avoid it entirely. Right, but we have installed base. Based upon comments in Jabber yesterday, I think that the right way is for fridge.local mDNS to return a series of SRV records in the additional information, one of which would contain a FQDN (having a GUA) for the fridge, if it had one. I don't know exactly what that would look like, but it seems like the right process: discovery gives us a name, and the name is sometimes a FQDN. That would also have solved Stuart's problem printing to bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather than bluehawaii.local (nothing that bluehawaii.apple.com works just fine when in the office) Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works=20 It might be reasonable for mDNS or dynamic DNS to populate the FQDN with an A and record and create a CNAME in local or sitelocal that points to the FQDN. Tools like host or dig would report the CNAME, the FQDN, and the final A and/or records if sitelocal was in the search path before the domain. I'm not sure how that works with CUPS bookmarking. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Do we want applications caching mDNS replies into configuration files? I think not, and I think the DNS people will shout loudly about that. Hm... I'm a DNS people, but I'm not sure I object to this. You'd want some mechanism for clearing old records out after the devices had been gone from the network for a long-enough time, but that's not intrinsically hard. I regularly print to both my work and home printer remotely (yes, over IPv6. The CUPS server speaks IPv6 even if my home printer speaks only USB). I'm of the opinion that remote access from offsite should be a service you can configure your printer to provide, but which is not the default. In my ideal world (please indulge me in a moment of handwaving), you plug in your printer, and tell it what its name is (or let it pick its own default such as LaserPrinter-3); it announces itself to the local network as providing local printing, and its name is placed in the .sitelocal domain. *If* you check the box for let the outside world print to me -- which you and I might want to do but most people wouldn't -- then it announces itself as providing both local and remote printing, and its name is placed in .sitelocal and then mirrored into the globally addressable domain that you'd previously configured for your network: by preference, that would be your private domain name, but if you don't have one of those then it could mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever. If you were printing something, and you a found a printer via service discovery which indicate that it could provide remote access, then you'd be given the option to bookmark its global name and use it when you're away; if it isn't configured for remote access then you woulnd't be given that option. A similar mental model could apply to the fridge and lamp examples we've been kicking around as well -- you won't normally *want* them to be globally accessible, but if you do, you should tell them so and let them work it out with your network. (This is the point I was trying to make at the mic yesterday, but I'm not sure it came across.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Evan == Evan Hunt e...@isc.org writes: Do we want applications caching mDNS replies into configuration files? I think not, and I think the DNS people will shout loudly about that. Evan Hm... I'm a DNS people, but I'm not sure I object to this. Evan You'd want some mechanism for clearing old records out after Evan the devices had been gone from the network for a long-enough Evan time, but that's not intrinsically hard. so, after your ISP renumberers you (not a flash renumber), or if you change routers (get a new ULA), or change ISPs, you have to discover your printer again? Evan I'm of the opinion that remote access from offsite should be Evan a service you can configure your printer to provide, but which Evan is not the default. Uhm, so let's seperate discovery, naming, and reachability from authorization. (being able to reach it doesn't mean you can print...) Evan In my ideal world (please indulge me in a moment of Evan handwaving), you plug in your printer, and tell it what its Evan name is (or let it pick its own default such as Evan LaserPrinter-3); it announces itself to the local network as Evan providing local printing, and its name is placed in the Evan .sitelocal domain. okay, so far. Evan *If* you check the box for let the outside world print to me Evan -- which you and I might want to do but most people wouldn't I agree that this is a box. I'd like to see some more authentication and authorization things happen, but that's a detail for CUPS/IPP. What's relevant here is that we have a new requirement for sitelocal mDNS: we need to signal via mDNS from the printer to the holder of the FQDN zone (probably the CPE). -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgp6yyByM7jRk.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] tunnels as way to disambiguate .local
Since I apparently got a few heads shaking today from my jabber comment, I guess I should at least throw it on the list. My observation -- and I'm not necessarily saying it's a [good] solution -- is that one way that we could deal with the ambiguity of what fridge.local[site] means when I elsewhere is to say that .local[site] is exactly what it says it is: a property of the local site. As such, if I'm roaming and do not have topological connectivity, the proper way to get that connectivity would be to use some form of tunneling back to the .local[site] I actually intended and thus be part of the .local[site] topology again. On the plus side, this puts it into the hands of somebody to deal with the ambiguity. On the minus side, this puts it into the hands of somebody to deal with the ambiguity. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
In message 50188eb0.2040...@mtcc.com Michael Thomas writes: Since I apparently got a few heads shaking today from my jabber comment, I guess I should at least throw it on the list. My observation -- and I'm not necessarily saying it's a [good] solution -- is that one way that we could deal with the ambiguity of what fridge.local[site] means when I elsewhere is to say that .local[site] is exactly what it says it is: a property of the local site. As such, if I'm roaming and do not have topological connectivity, the proper way to get that connectivity would be to use some form of tunneling back to the .local[site] I actually intended and thus be part of the .local[site] topology again. On the plus side, this puts it into the hands of somebody to deal with the ambiguity. On the minus side, this puts it into the hands of somebody to deal with the ambiguity. Mike For a mobile device, including a laptop, sitelocal should reflect where you are. In someone else's house, printer.sitelocal should be their printer. If that someone else gives you authentication credentials or you give then a public key and they install it on the printer, then you can print. Today, more likely the home printer is USB and you plug it in to your laptop. Getting to your own fridge or printer from elsewhere would require that you have a domain name and know what your domain name is. Presumably you'd already have whatever you need for authentication. There is no ambiguity. It is a personal choice whether you want to put sitelocal first in the search path or your own domain first. I suggest that your own domain would be a better choice. fridge means the same thing no matter where you are. fridge.sitelocal means the fridge near you if you are elsewhere. fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] tunnels as way to disambiguate .local
Correction. A mobile device on the a site's wireless LAN would see fridge.sitelocal. The cellular provider would be better off just populating sitelocal with any services offerred by the cellular provider, such as mediadownload.sitelocal or ntp.sitelocal (unlikely, but hopeful). Sitelocal might be problematic for a mobile phone in a fast moving car on a highway through an urban area. Sitelocal would change with each cell tower handoff. Curtis In message 201208010448.q714m8ki091...@gateway.ipv6.occnc.com Curtis Villamizar writes: In message 50188eb0.2040...@mtcc.com Michael Thomas writes: Since I apparently got a few heads shaking today from my jabber comment, I guess I should at least throw it on the list. My observation -- and I'm not necessarily saying it's a [good] solution -- is that one way that we could deal with the ambiguity of what fridge.local[site] means when I elsewhere is to say that .local[site] is exactly what it says it is: a property of the local site. As such, if I'm roaming and do not have topological connectivity, the proper way to get that connectivity would be to use some form of tunneling back to the .local[site] I actually intended and thus be part of the .local[site] topology again. On the plus side, this puts it into the hands of somebody to deal with the ambiguity. On the minus side, this puts it into the hands of somebody to deal with the ambiguity. Mike For a mobile device, including a laptop, sitelocal should reflect where you are. In someone else's house, printer.sitelocal should be their printer. If that someone else gives you authentication credentials or you give then a public key and they install it on the printer, then you can print. Today, more likely the home printer is USB and you plug it in to your laptop. Getting to your own fridge or printer from elsewhere would require that you have a domain name and know what your domain name is. Presumably you'd already have whatever you need for authentication. There is no ambiguity. It is a personal choice whether you want to put sitelocal first in the search path or your own domain first. I suggest that your own domain would be a better choice. fridge means the same thing no matter where you are. fridge.sitelocal means the fridge near you if you are elsewhere. fridge.sitelocal. is a FQDN with site local scope. fridge.yourdomain is a FQDN with global scope. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
