Subject: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt

From: [email-masked]
Date: Fri, 19 Oct 2012 09:00:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

	Title           : Home Networking Architecture for IPv6
	Author(s)       : Tim Chown
                          Jari Arkko
                          Anders Brandt
                          Ole Troan
                          Jason Weil
	Filename        : draft-ietf-homenet-arch-05.txt
	Pages           : 43
	Date            : 2012-10-19

Abstract:
   This text describes evolving networking technology within
   increasingly large residential home networks.  The goal of this
   document is to define an architecture for IPv6-based home networking,
   while describing the associated principles, considerations and
   requirements.  The text briefly highlights the specific implications
   of the introduction of IPv6 for home networking, discusses the
   elements of the architecture, and suggests how standard IPv6
   mechanisms and addressing can be employed in home networking.  The
   architecture describes the need for specific protocol extensions for
   certain additional functionality.  It is assumed that the IPv6 home
   network is not actively managed, and runs as an IPv6-only or dual-
   stack network.  There are no recommendations in this text for the
   IPv4 part of the network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-arch

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-arch-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Chown <[email-masked]>
Date: Fri, 19 Oct 2012 17:36:42 +0100

Hi all,

The architecture text has been updated to -05.

See: http://tools.ietf.org/html/draft-ietf-homenet-arch-05

We can take comments towards a -06 over the weekend.  The most substantial changes are in the Naming and Service Discovery section (3.7), so if you have limited time please focus your reading there.

One item where there seemed to be a lack of a firm conclusion (despite some firm statements each way) was the question of using a single global name space or separate internal and external name spaces. The current text essentially says:
* The default is to use an ISP-provided domain in the homenet, but with the user able to use an independent domain name instead if preferred.
* If no global domain is available, the homenet uses either a ULQDN (preferred) or ALQDN, and these are scoped to the local homenet (i.e. the homenet can only be reached remotely if using a global domain).

The open issue is whether the LQDN should be used alongside a global FQDN if one is available (with appropriate mappings/CNAMEs and reverse entries to the global FQDN as proposed I think by Curtis), or if the global domain is available then no local domain should be used.

Tim

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Oct 2012 09:55:20 -0700

> * If no global domain is available, the homenet uses either a ULQDN (preferred) or ALQDN, and these are scoped to the local homenet (i.e. the homenet can only be reached remotely if using a global…

If you get an ISP's name couldn't you always with or without their cooperation
generate names of the form host.<uniquestring>.isp.net? Where <uniquestring>
is either statistically unique (cf ULA's), or is human-significant and unique (eg,
host.casasanchez.customers.isp.net).

Doing so would potentially take the "otherness" of .local away, and make the
human factors issue less stark. Also: if we end up with a repository in the
CPE, say, it makes transitions between vanity domains, hosted domain (ala
ISP or some cloud service), and local/isolated domains easier it seems to me.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Oct 2012 10:16:29 -0700

> We can take comments towards a -06 over the weekend.  The most substantial changes are in the Naming and Service Discovery section (3.7), so if you have limited time please focus your reading there.

One thing that I'm not sure whether it's been discussed or not is service announcement.
By service announcement, I mean where instead of multicasting out a message looking
for the canonical printer with all of its nasty properties especially for things with batteries
and lossy/slow networks, a device would instead announce its presence to something
that would later serve it up (eg, bind9, say).

That is, if we can posit a dns repository in our home edge routers, we can avoid some
of the insanity that ensues when you say that something MUST be strictly zeroconf.
I think we are long past the days where strict zeroconf should be the driving principle;
littleconf should be a valid option too.

Service announcement could also feed into things like Search where instead of
having preset categories which make sense perhaps only to those who chose the
category at the factory, we could also have structured and/or free-form text with
lots of  keywords and other identifying information that an indexer might find useful.

Mechanistically, we already have things like IXFR for DNS, so it's not likely that
this is wholesale invention, though it may well involve some tweaks. IXFR also
gives the possibility for enrollment and access control which is pretty problematic
with service discovery.

Mike

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 15:22:14 +0100

Hi Mike,

Thanks for the comments.

> that would later serve it up (eg, bind9, say).

I think this is covered in 3.7.4, certainly possible.

> littleconf should be a valid option too.

And I don't think this possibility is excluded at all by the current arch text either. It talks of an authoritative name service running on the CER, with a dynamic registration service (e.g. dyndns).  I have added 'as far as possible' to the unmanaged text.

> lots of  keywords and other identifying information that an indexer might find useful.

That's probably straying a little into the UI side.  Again, I don't think we preclude that.  

> gives the possibility for enrollment and access control which is pretty problematic

I think these issues may come up in the mdnsext BoF - I encourage you to join that list and give comment there.

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 15:26:29 +0100

> host.casasanchez.customers.isp.net).

I would assume here that the name the ISP delegates includes such a unique string, e.g. cust1234.someisp.net.  Maybe for an extra fee they'll let you pick a unique string to replace 'cust1234'.  Personally (and I note at IETF85 we found that half the homenet attendees had 110+ domains each!) I believe it's important to allow the homenet to use an ISP-independent domain name as simply as possible.

> ISP or some cloud service), and local/isolated domains easier it seems to me.

Certainly keeping as much of this as simple as possible for the homenet user, while not precluding more advanced options, is important.

tim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 Oct 2012 09:15:09 -0700

> And I don't think this possibility is excluded at all by the current arch text either. It talks of an authoritative name service running on the CER, with a dynamic registration service (e.g. dyndns…

It's been hard for me to gauge what is and isn't in scope on the naming
front. For the most part, this wg looks like it's only interested in putting
some band-aides on mdns/dns-sd. That's a mistake, IMO, because there's
nothing inevitable about a zeroconf driven design. We should consider
littleconf solutions especially for naming because there is no way that
mikes-toothbrush.mtcc.com got named that way coming from the factory.

> I think these issues may come up in the mdnsext BoF - I encourage you to join that list and give comment there.
Correct me if I'm wrong, but I'd think that a mdnsext bof is interested in
extending mdns. What I'm talking about has nothing to do with multicast,
dns or otherwise. So I'm not sure that my participation would be all that
welcome.

Mike

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 22 Oct 2012 12:30:57 -0400

On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas <[email-masked]> wrote:

>> And I don't think this possibility is excluded at all by the current arch
>> text either. It talks of an authoritative name service running on the CER,
>> with a dynamic registration service (e.g. dyndns).  I have added 'as far as
>> possible' to the unmanaged text.
>>
>

Not sure how you can draw that conclusion; there seem to be lovers and
haters of mDNS.  To the extent that it's unsuited for multi-link topologies,
a BoF has been approved to discuss problems and requirements.  I hope
that folks interested in a DNS-based solution to service discovery and
naming will join the mdnsext mailing list.

I have nothing wrong with littleconf per se, but there seems to me a chicken
and egg problem: how does one engage a device (presumably running a
web-based UI) initially in order to administer it?  Is that by address or by
name?  If by name, then how does it work?

> The mdnsext BoF is interested in extensions to DNS-SD and mDNS, including
the possibility of using the latter to bootstrap (seed) a DNS directory,
perhaps
under some guidance from a lay user.

Regards, -K-

Mike
>
> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Oct 2012 17:31:49 +0100

On 19/10/2012 18:16, Michael Thomas wrote:
>> We can take comments towards a -06 over the weekend.  The most
>> substantial changes are in the Naming and Service Discovery section
>> (3.7), so if you have limited time please focus your reading there.
> 

e.g. an SLP Directory Agent, designed for this purpose some years ago.
[RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832]
This is not exactly a new problem.

   Brian

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 Oct 2012 09:42:31 -0700

On 10/22/2012 09:30 AM, Kerry Lynn wrote:
> On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas <[email-masked] <mailto:[email-masked]>> wrote:
>
>     mikes-toothbrush.mtcc.com <http://mikes-toothbrush.mtcc.com> got named that way coming from the factory.
>
>

As I mentioned, what I'm thinking about doesn't need multicast at
all. So it would be pretty bizarre to discuss getting rid of the need
for multicast dns on a mailing list that is bent on extending it.

> name?  If by name, then how does it work?

The device just announces itself to a repository, and the repository serves
up its name. No need to multicast each time you need to resolve a name,
it just unicasts it or maybe anycasts it at boot time, perhaps on a renewal
timer. If the rfc's that Brian's note references are applicable, so much the
better.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 Oct 2012 10:30:18 -0700

> This is not exactly a new problem.

I looked this over, and I don't think it's what I'm thinking of. I'm
thinking of literally having a device do an IXFR to a real DNS server.
Or something that looks pretty similar to an IXFR, but the key being
that it's a real DNS server. No multicast required ever.

In any case, even if this isn't new ground maybe the problem was that
they didn't hitch their wagon to DNS. Deployment of SLP is I'm guessing
pretty thin.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 Oct 2012 11:49:27 -0700

On 10/22/2012 07:26 AM, Tim Chown wrote:
> I would assume here that the name the ISP delegates includes such a unique string, e.g. cust1234.someisp.net.  Maybe for an extra fee they'll let you pick a unique string to replace 'cust1234'.  Personally (and I note at IETF85 we found that half the homenet attendees had 110+ domains each!)

That's assuming that the ISP knows anything about me camping on
their namespace at all. If I run a DNS locally -- say in my home router --
I could use their name space regardless of whether they sanction it
or not. It might only work in my home, of course (ie, users of my
DNS server that is camping on somebody else's namespace).

> I believe it's important to allow the homenet to use an ISP-independent domain name as simply as possible.

Right, and is the reason that the DHCP linkage of the Orange draft
is problematic.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 22 Oct 2012 12:00:28 -0700

On 10/22/2012 09:30 AM, Kerry Lynn wrote:
> haters of mDNS.

I just re-read the charter and it seems that it precludes discussing anything
else besides mdns/dns-sd:

  For name
     resolution and service discovery, extensions to existing
     multicast-based name resolution protocols are needed to enable them to
     work across subnets.

I wasn't around for the drafting of the charter, but it seems very short sighted
to not even talk about what the problem is before mandating a solution. So
if you don't think mdns is The Answer, it looks like you're SOL.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2012 11:38:29 +0100

> they didn't hitch their wagon to DNS. Deployment of SLP is I'm guessing

I'm told that it's widely implemented (at least in printers) but rarely
used. All I'm saying is that it should be on the candidate list.

(And if the WG charter limits the list of candidates, that's a bug in
the charter that will need to be fixed.)

      Brian