In message <47437c06-fb3d-41ab-adb9-01a409164...@nominet.org.uk>
Ray Bellis writes:
> An interesting question has come up during the Arch Doc team's
> discussions around naming and service discovery:
>
> "What in-home services actually require Unicast DNS lookup?" [*]
>
> The one obvious case is in-home web servers (i.e. CPE configuration)
> although a prior posting suggested that most people just use an IPv4
> address (e.g. 192.168.1.1) rather than a DNS name for that. Many
> devices now support Bonjour for that.
>
> If it can be shown that Unicast DNS is only need for resolution of
> _external_ names then much of the discussion around _internal_ naming
> probably becomes moot.
>
> thanks,
>
> Ray
>
> [*] I'm specifically _not_ talking about normal recursive DNS for
> global DNS names.
Ray,
I've read the thread so far and I'm replying to the original message.
The app that needs DNS is anything from outside or from a mobile
device that requires access to the home without going through a cloud
intermediary (usually not free).
PC to PC SIP is one example, optionally with video. The most common
intermediary is skype. There are also numerous SIP providers that
essentially broker the initial connection for free (handle the SIP
part, not the RTP part) and only charge if you connect to the PSTN
where they are usually a SIP back to back UI connection and incur a
fee from the PSTN. There is no reason why SIP URLs could not be used
with IPv6. Admittedly, not a popular idea with the phone companies.
For IPv4 today the cloud intermediary is a necessary evil due to both
side being behind a NAT and having no means to get a DNS name for
themselves. With IPv6 this can be solved. With IPv6 if we get it
right you won't need to go through a third party to change your
thermostat because you just found out that you are coming home early -
you can directly address your thermostat by name (hopefully with
reasonable authentication).
At issue is whether the homenet WG is going to continue with PC world
business as usual, which is lame discovery protocols that work only
when there is only one subnet and are useless otherwise.
One argument for multiple subnets is that bridging the GbE segment to
the WiFi segment can swamp the WiFi segment. By routing between the
two, active queue management (QoS) is easier and all of the segment
broadcast and multicast on the GbE segment need not appear on the
wireless.
There are other motivations such as having an open guest wireless
channel vs having a secure wireless channel, plus a wired segment.
WiFi home routers able to support two channels are not uncommon today,
though they are on the high end of home stuff (available on the
shelves of you consumer and office supply places). It is better not
to bridge the guest and secure segments together but rather to route
between them.
With IPv6 and the prospect of GUA for everything, the practice of
hiding horribly insecure devices and protocols behind a firewall needs
to disappear. It has proven unsafe over and over in enterprise of any
size, where one compromise exposes the entire private side.
If it is not DNS, it has to meet some requirements:
1. work over multiple subnets
2. tie into DNS if devices are to be accessed from elsewhere
If it is DNS, it has to meet some requirement that DNS as practiced
isn't very good at right now.
1. there needs to be a means of creating a namespace without going
to a registry first (entirely local, but provider delegation
would be better)
2. a usable interface is needed to assign names to devices (dyndns
is almost adequate, setting host name on each device, but better
would be to assign names centrally - configured dhcp entries)
In either case where multiple routers are encountered, some means to
resolve who is in charge of the name space is needed.
Or we can continue with yet another lame half-baked solution de-jour
for a single subnet home carrying forward the thinking of NATed PI
addresses behind a firewall and have a different set of solutions for
soho, small business, and up.
Regarding some of the other comments.
... I see the point about the home with wireless audio and video
components. There is only so much that can be done in a dorm or other
high density housing (apartments) where having many WiFi APs crowd the
channel space. Even where I live, where lots are 1.5-2.5 acres, I saw
today 6 APs, three on channel 6, when I looked at my wife's laptop to
see why it was having a bad day. This is why many dorms have wired
Ethernet, and that tried to go all wireless and switched back. The
campus library, the dorm lounges, etc still have wireless. Due to
virus and worm problems MAC addresses need to be registered with
campus IT before a student device is granted access. Only very public
places like lounges and library have open wireless and are somewhat
isolated (untrusted guest treatment). Of course students can still
bring in wireless routers and NAT and make a mess of things (and do).
... Brian, I agree that two namespaces is evil (or whatever you called
it). I also agree that if it is not DNS there needs to be a very good
reason.
Curtis
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
