Subject: [homenet] NPTv6-only home networks

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2013 11:37:53 +0900

On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas <[email-masked]> wrote:

> That's why we have ULAs and multiple prefixes.
>>
>
> ULA's are of limited use. I still want to start my washing machine
> regardless of whether I'm at home or not.

And you'll know the current IPv6 address of that washing machine how? If
you assume renumbering, then the inevitable conclusion is  that the address
at which you can reach the washing machine from outside your home will
change. Therefore, something has to store that address somewhere that's
accessible from outside the home, and it has to update it frequently enough
that there are no significant outages.

I don't see how this requirement is different whether you use NPTv6+ULA or
dynamic global addresses. The only difference that I see is that in the
case where the machine has a global address, it knows what that address is
without having to ask a rendezvous server outside the network. In the case
where it only has ULA, it doesn't know what its address is unless it asks a
server.

>      I don't like to think that NAT is inevitable but frankly the people
>>     in this working group don't get to vote on that.
>>
>>
>> Actually they do. They have the freedom to specify alternatives, and
>> depending on how good a job they do, implementers may choose to use them.
>>
>
> Wishful thinking. NAT's didn't start with the blessing of IETF as I
> recall. They just
> happened. If the alternatives are too whacked out, history will repeat
> itself.

Exactly. This group can specify alternatives, and if they're good enough,
they'll get used.

I think NAT became popular because users didn't want to pay ISPs twice to
connect two devices. That was a pretty strong incentive. I think the
incentives are much weaker with IPv6 now that residential ISPs provide at
least a /64, and in most cases much more.

>     Speaking to the title of this thread: has anybody actually
>
>>     demonstrated such a thing end to end? It strikes me as
>>     Frankensteinian when you get all of the body parts bolted together.
>>
>>
>> What thing exactly? Multiprefix multihoming? End-to-end connectivity in
>> general?
>>
>
> Yes, along with naming, security, prefix delegation across multiple
> routers, and isp's
> giving and withdrawing prefixes due to renumbering. I'm dubious that this
> has happened
> in real life with networks with people whose day job is to worry about
> such things, and
> I'd be astonished to hear such a thing has been shown to work on a home
> network.
>

I don't know about naming and security, but renumbering works using address
deprecation (that's been in the spec since forever), and since it's covered
by RFC6204 and there are conformance tests for it, devices with the
appropriate logo will support it. Support for prefix delegation across
multiple routers is spotty, and there's no way to make it work in arbitrary
topologies, but for what it's worth, I run it at home and it does work (my
operator-provided CPE supports DHCPv6 PD and all I needed to do was plug in
an IPv6-capable CPE). source+destination based routing has been
demonstrated to work.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2013 19:04:01 -0800

Lorenzo Colitti wrote:
> On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> you assume renumbering, then the inevitable conclusion is  that the 
> address at which you can reach the washing machine from outside your 
> home will change. Therefore, something has to store that address 
> somewhere that's accessible from outside the home, and it has to update 
> it frequently enough that there are no significant outages.

Yes, that is the conclusion. The thing that I hold out some hope that we won't
be sucked down the NAT septic tank this time around is that the need to globally
address things on my home network won't be a geek-only oddity, but a real live
requirement that needs to be solved unlike NATv4.

Now do I have a lot of belief that this works well in real life? No, not really.
Particularly about naming, and the things being tossed around here give me
little hope that problem is even understood, let alone that solutions will be
forthcoming.

> I don't see how this requirement is different whether you use NPTv6+ULA 
> or dynamic global addresses. The only difference that I see is that in 
> the case where the machine has a global address, it knows what that 
> address is without having to ask a rendezvous server outside the 
> network. In the case where it only has ULA, it doesn't know what its 
> address is unless it asks a server.

Yes, NPTv6 as I recall begs the question of split resolvers and all of the
ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong.

> Exactly. This group can specify alternatives, and if they're good 
> enough, they'll get used.

I don't think that it's controversial to say that any solution that takes
into account the many things we want to accomplish is going to be complex.
Far more complex than what the average home-router-with-nat does right now.
Rube Goldberg is not our friend here. It scares me.

> I think NAT became popular because users didn't want to pay ISPs twice 
> to connect two devices. That was a pretty strong incentive. I think the 
> incentives are much weaker with IPv6 now that residential ISPs provide 
> at least a /64, and in most cases much more.

Yes, there were many reasons but the real point is that the IETF could scream
foul, issue rfc's (i'm not really sure it ever did, but...) and generally try
to stay relevant, but it didn't really matter. Utility fsvo "utility" 1,
architecture 0.

> I don't know about naming and security, but renumbering works using 
> address deprecation (that's been in the spec since forever), and since 
> it's covered by RFC6204 and there are conformance tests for it, devices 
> with the appropriate logo will support it. Support for prefix delegation 
> across multiple routers is spotty, and there's no way to make it work in 
> arbitrary topologies, but for what it's worth, I run it at home and it 
> does work (my operator-provided CPE supports DHCPv6 PD and all I needed 
> to do was plug in an IPv6-capable CPE). source+destination based routing 
> has been demonstrated to work.

Naming is the one thing I'm almost certain is out in la-la land even in the
big leagues. For home I'm pretty certain that handwaving would be a generous
description of the current state of affairs. And then there's securing things
which is always great for a good belly laugh.

Mike

---

From: David Lamparter <[email-masked]>
Date: Fri, 22 Feb 2013 04:32:42 +0100

On Thu, Feb 21, 2013 at 07:04:01PM -0800, Michael Thomas wrote:
> > And you'll know the current IPv6 address of that washing machine how?

[...snip..]

> Rube Goldberg is not our friend here. It scares me.

Well, I wasn't able to find numbers on what percentage of CPEs is
Linux-based these days, but, in all honesty, I think if there is a
ready-made package for this, maybe even in OpenWRT, that will have a
major impact on proliferation of pretty much anything in the CPE area.

[...snip...]

> which is always great for a good belly laugh.

Indeed I have to agree on this one from practical experience.  We've
tried creating some kind of automatic IPv6 naming system at the local
hackerspace - with 2 network software developers, no less - and failed.
We're using SLAAC (which AFAIK is reasonable to expect in a homenet?)
and a good percentage of our devices don't speak MDNS.  We didn't even
get as far as thinking about privacy addresses, we just failed to find
any reasonable way to get names to start with...
(Ok, well, maybe MDNS would've been the way to go... but, being targeted
at local name resolution, this is nowhere near a turn-key solution for
accessing a washing machine from the internet either.)

-David

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Feb 2013 22:42:14 -0500

> any reasonable way to get names to start with...

It's probably worth bearing in mind that the solution for your problem hasn't been standardized yet, nor is there even rough consensus on what the standard ought to look like, and so nobody's got it implemented in devices.

Basing our expectations on what the best we can do is on what we have now is a recipe for failure.   We should set our sights on doing it right, and accept that it won't be done right in the very earliest IPv6 homenets.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2013 19:45:59 -0800

> Basing our expectations on what the best we can do is on what we have now is a recipe for failure.   We should set our sights on doing it right, and accept that it won't be done right in the very e…

Well, if one of the requirements is that I be able to control my washing machine from across the continent,
I'm not sure why we're even screwing with mdns in this wg. And if that's not a requirement for this working
group, I have to ask which century it got chartered in.

Mike

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2013 13:31:14 +0900

> ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong.

My point was more that that NPTv6 doesn't make that any easier, more
secure, or... anything, really. You still have to update the address
somewhere; all that NPTv6 gives you is that now the washing machine doesn't
know what its IPv6 address is. Right?

---

From: joel jaeggli <[email-masked]>
Date: Fri, 22 Feb 2013 00:02:08 -0800

On 2/21/13 7:04 PM, Michael Thomas wrote:
>> If you assume renumbering, then the inevitable conclusion is  that 
>> the address at which you can reach the washing machine from outside 
>> your home will change. Therefore, something has to store that address 
>> somewhere that's accessible from outside the home, and it has to 
>> update it frequently enough that there are no significant outages.
>
So, I think what we can observe from the number of readily discoverable 
security cameras on the internet. was that the real-live requirement was 
at least partially solved thanks to upnp and dynamic dns registration, 
is not a geek-only-oddity, survives renumbering, and was for the most 
part done quite badly. hopefully it can be done better in the future.
>> I don't see how this requirement is different whether you use 
>> NPTv6+ULA or dynamic global addresses. The only difference that I see 
>> is that in the case where the machine has a global address, it knows 
>> what that address is without having to ask a rendezvous server 
>> outside the network. In the case where it only has ULA, it doesn't 
>> know what its address is unless it asks a server.
>
>> I think NAT became popular because users didn't want to pay ISPs 
>> twice to connect two devices. That was a pretty strong incentive. I 
>> think the incentives are much weaker with IPv6 now that residential 
>> ISPs provide at least a /64, and in most cases much more.
>
>> address deprecation (that's been in the spec since forever), and 
>> since it's covered by RFC6204 and there are conformance tests for it, 
>> devices with the appropriate logo will support it. Support for prefix 
>> delegation across multiple routers is spotty, and there's no way to 
>> make it work in arbitrary topologies, but for what it's worth, I run 
>> it at home and it does work (my operator-provided CPE supports DHCPv6 
>> PD and all I needed to do was plug in an IPv6-capable CPE). 
>> source+destination based routing has been demonstrated to work.
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2013 08:49:01 +0000

On 22/02/2013 03:45, Michael Thomas wrote:
...
> machine from across the continent,

Actually we need to be clear about that requirement. There are
at least three cases I can imagine:

1. I want to control my washing machine remotely (although I
won't be doing that until I have a very reliable dhobi-robot to
load and unload it).

2. The manufacturer wants to update my washing machine remotely.

3. A benevolent 3rd party wants to control it remotely.

I think you'll find each of these cases has different discovery,
naming and security requirements.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 07:27:29 -0500

> group, I have to ask which century it got chartered in.

+1

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 07:30:48 -0500

On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti <[email-masked]> wrote:
> My point was more that that NPTv6 doesn't make that any easier, more secure, or... anything, really. You still have to update the address somewhere; all that NPTv6 gives you is that now the washing machine doesn't know what its IPv6 address is. Right?

I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up.   However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 07:37:13 -0500

>> group, I have to ask which century it got chartered in.

Er, that came out wrong.   I'm agreeing with "want to be able to access devices in the home from away," not "working group was chartered in the last century."  I am also skeptical about MDNS as a solution, though.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Feb 2013 12:42:36 +0000

On 22 Feb 2013, at 03:45, Michael Thomas <[email-masked]> wrote:

> Well, if one of the requirements is that I be able to control my washing machine from across the continent, I'm not sure why we're even screwing with mdns in this wg. And if that's not a requirement for this working group, I have to ask which century it got chartered in.

It's indirectly mentioned in the charter:

"While IPv6 resembles IPv4 in many ways, it changes address
 allocation principles and allows direct IP addressability
 and routing to devices in the home from the Internet."

  ...

"End-to-end communication is both an opportunity and a
 concern as it enables new applications ..."

and it's also explicitly called out in draft-ietf-homenet-arch (§3.7)

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Feb 2013 12:49:05 +0000

On 22 Feb 2013, at 12:37, Ted Lemon <[email-masked]>
 wrote:

> Er, that came out wrong.   I'm agreeing with "want to be able to access devices in the home from away," not "working group was chartered in the last century."

:)

>  I am also skeptical about MDNS as a solution, though.

<nohat>

Personally, I think there's still a good argument to be made for reserving "normal unicast DNS" for access to globally addressable resources (be that from the home to the outside, or from the outside into the home), whilst using "some other protocol" for truly internal name resolution.

I *really* don't like the idea of each individual Homenet having to create some sort of randomised namespace for its internal DNS.

Ray

---

From: Simon Kelley <[email-masked]>
Date: Fri, 22 Feb 2013 13:00:48 +0000

> I think the issue that Michael imagines NPTv6 will address is the
> transition period, when the washing machine has two IP addresses, and
> the DNS may not have the new address, or may have both addresses, and
> he's hoping the gateway will somehow bandage this up.   However, the
> gateway's ability to bandage this up is more imagined than real, and
> we might as well just fix the underlying problem.

The current development release of dnsmasq can act as an authoritative
DNS server populated with all hosts on a homenet which it knows about
from DHCP. Delegate your domain to it, and ensure  that the TTL
configured for DNS is smaller than the deprecated lifetime of addresses,
and this problem should never arise.

---

From: David Lamparter <[email-masked]>
Date: Fri, 22 Feb 2013 14:07:48 +0100

> and this problem should never arise.

This only works with stateful DHCPv6 though?

-David

---

From: Simon Kelley <[email-masked]>
Date: Fri, 22 Feb 2013 13:24:46 +0000

> This only works with stateful DHCPv6 though?

It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts
would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers
an awful lot of currently-deployed clients.

The IPv4 addresses can be RFC1918, the DHCPv4 lease is used to give
dnsmasq the MAC address and name of a client. The authoritative DNS
module is configurable to expose global IPv6 addresses and hide RFC1918
IPv4 addresses.

Simon.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 09:49:43 -0500

> I *really* don't like the idea of each individual Homenet having to create some sort of randomised namespace for its internal DNS.

I don't either, but that's not the only way to approach the problem.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 09:50:50 -0500

> an awful lot of currently-deployed clients.

So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration?

---

From: Michael Thomas <[email-masked]>
Date: Fri, 22 Feb 2013 07:01:36 -0800

> I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addres…

Just to be perfectly clear, I'm not imagining NPTv6 working at all. (and how did this get turned into npt vs nat?)
My fear is that the complexity of all of this will drive people and manufacturers to "simple" and brain dead solutions
that do not meet the requirement that I be able to control my washing machine across the continent, for example.
Renumbering is something that has gotten a lot of attention over the years in ietf, but its intersection with naming
is still problematic as far as I can tell in the real world, and is likely to be even more problematic in with low-clue
home networks.

Right now, I don't think that sufficient energy is being given to just one obvious problem: how does real DNS interact with
prefix delegation in the home (assuming that we don't want split horizon dns)? For that matter, let me be even more blunt:
I don't think that real DNS is being given enough attention altogether in home settings, and until that happens we'll
just inherit all of the awful hacks that are done with NATv4.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 22 Feb 2013 07:24:26 -0800

> part done quite badly. hopefully it can be done better in the future.

I was under the impression that upnp is exactly what we should not be aspiring to,
but that we'll get by default (like natv6) if nothing useful happens in ietf.

Mike

---

From: joel jaeggli <[email-masked]>
Date: Fri, 22 Feb 2013 07:49:58 -0800

On 2/22/13 7:24 AM, Michael Thomas wrote:
>> So, I think what we can observe from the number of readily 
>> discoverable security cameras on the internet. was that the real-live 
>> requirement was at least partially solved thanks to upnp and dynamic 
>> dns registration, is not a geek-only-oddity, survives renumbering, 
>> and was for the most part done quite badly. hopefully it can be done 
>> better in the future.
>
my point was not that upnp was worth aspiring too. it was that the 
existence proof for servers in the home is all over the place even in 
the the state of brokenness.

---

From: Simon Kelley <[email-masked]>
Date: Fri, 22 Feb 2013 15:53:37 +0000

> So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration?
As the DHCPv4 state machine moves to "lease complete" it spits a (MAC
address, hostname, broadcast domain) tuple over to the IPv6 side.
The broadcast domain plus configuration yields a list of prefixes, and
the MAC address gets turned into a SLAAC host-identifier. The two make a
set of putative addresses. The state machine then sends an ICMP6 echo
request to each putative address and if it responds then that address is
added as an AAAA record with the hostname.

There are some implementation details involving timeouts and retries and
sending speculative router advertisements to ensure that a
new-on-the-network host is ready to reply to the pings.

The practice is that it always works, even a smartphone moving slowly
into a dodgy Wifi network. If the client can get a DHPCv4 lease, the
IPv6 SLAAC address gets a name too.

Simon.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 14:44:09 -0500

> just inherit all of the awful hacks that are done with NATv4.

Agreed.   I'm delighted to hear that Simon has a hack in dnamasq that addresses this problem in a dual-stack environment, but I want to have a serious conversation somewhere about how to address the problem on the v6-only homenet.

Who's interested in sketching a DNS-based solution to the problem and has time to work on it?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Feb 2013 14:48:58 -0500

> IPv6 SLAAC address gets a name too.

That is _very_ cool.   Nice work!

---

From: Simon Kelley <[email-masked]>
Date: Fri, 22 Feb 2013 20:08:26 +0000

> That is _very_ cool.   Nice work!

I make no claims for the invention, only the implementation. I'm aware 
of it being independently invented at least twice, involving at least 
three different people.

Simon.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Feb 2013 11:19:40 -0500

>>>>> "Erik" == Erik Kline <[email-masked]> writes:
    >> I don't know about naming and security, but renumbering works
    >> using address deprecation (that's been in the spec since
    >> forever), and since it's covered by RFC6204 and there are
    >> conformance tests for it, devices with the appropriate logo will
    >> support it.

    Erik> I wonder if we should ask the NOC about performing a
    Erik> renumbering during the next IETF meeting.

v6 or v6 and v4?

Given happy eyeballs, how will we measure the impact of a v6-only
renumbering?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Erik Kline <[email-masked]>
Date: Sat, 23 Feb 2013 14:53:00 +0900

> appropriate logo will support it.

I wonder if we should ask the NOC about performing a renumbering
during the next IETF meeting.

Ideally, we should be able to perform one or two (or three)
renumberings in a week, glean the relevant operational experience, and
send a draft to v6ops shortly thereafter.

Ideally...

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Feb 2013 08:27:38 +0000

On 23/02/2013 05:53, Erik Kline wrote:
..
> send a draft to v6ops shortly thereafter.

Great idea. I won't be in Orlando, but I am fairly sure there is nothing
I would do there that cares about address persistency, apart from
having to reconnect to jabber maybe. Conducting an RFC 4192 procedure
on Tuesday night and a flash IPv6 renumbering during Thursday morning
would be very interesting!

At least Skype will not be a problem during IPv6 renumbering.

    Brian

---

From: Michael Thomas <[email-masked]>
Date: Sat, 23 Feb 2013 05:41:38 -0800

> send a draft to v6ops shortly thereafter.

The only way that this would have relevance that is specific to the emerging v6 homenet
is if there were servers being renumbered too, and how that affects global connectivity.
If we're not planning for this, then we're ignoring one of the most important things that
v6 homenets will provide.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Feb 2013 19:37:13 +0000

> Given happy eyeballs, how will we measure the impact of a v6-only

By a reduction in IPv6 traffic after the event?

In any case, to some extent it's a pass/fail test (where "pass" = "no complaints").

Regards
   Brian

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 24 Feb 2013 17:29:00 +0000

>somewhere; all that NPTv6 gives you is that now the washing machine
>doesn't know what its IPv6 address is. Right?
[jjmb] yes and I agree with your points.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 24 Feb 2013 17:31:09 +0000

I thought mdnsext was supposed to handle this now?  Still agree it should
be covered some where.

-----Original Message-----
From: Ted Lemon <[email-masked]>
Date: Friday, February 22, 2013 4:27 AM
To: Michael Thomas <[email-masked]>
Cc: Michael Richardson <[email-masked]>, Mark Townsley
<[email-masked]>, Dave Taht <[email-masked]>, Jari Arkko
<[email-masked]>, John Jason Brzozowski
<[email-masked]>, "[email-masked] Group"
<[email-masked]>, Lorenzo Colitti <[email-masked]>, David Lamparter
<[email-masked]>
Subject: Re: [homenet] NPTv6-only home networks

>> Well, if one of the requirements is that I be able to control my
>>washing machine from across the continent,
>> I'm not sure why we're even screwing with mdns in this wg. And if
>>that's not a requirement for this working

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 24 Feb 2013 17:34:29 +0000

Do you populate A-DNS with hosts learned from mDNS and advertise hosts in
A-DNS via mDNS?  :O

=========================================
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) [email-masked]
o) 609-377-6594
w) www.comcast6.net
=========================================

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 24 Feb 2013 17:41:35 +0000

DLNA seems to have some challenges seeing how IPv6 is relevant for them in
the future, I think UPnP has done some work however upper layer
protocols/applications must still require the use of the same.

-----Original Message-----
From: Michael Thomas <[email-masked]>
Date: Friday, February 22, 2013 7:24 AM
To: Joel Jaeggli <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>, Michael Richardson
<[email-masked]>, Mark Townsley <[email-masked]>, Dave Taht
<[email-masked]>, Jari Arkko <[email-masked]>, John Jason
Brzozowski <[email-masked]>, "[email-masked] Group"
<[email-masked]>, David Lamparter <[email-masked]>
Subject: Re: [homenet] NPTv6-only home networks

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 24 Feb 2013 17:43:40 +0000

I have to agree kudos to Simon for trying to move something forward and
the something pertains to real problems that we must solve.  While I
recognize that is not in the HOMENET charter I do not agree that this
should be IPv6 only.

-----Original Message-----
From: Ted Lemon <[email-masked]>
Date: Friday, February 22, 2013 11:44 AM
To: Michael Thomas <[email-masked]>
Cc: Michael Richardson <[email-masked]>, Mark Townsley
<[email-masked]>, David Lamparter <[email-masked]>, Lorenzo Colitti
<[email-masked]>

>> Right now, I don't think that sufficient energy is being given to just
>>one obvious problem: how does real DNS interact with
>> prefix delegation in the home (assuming that we don't want split
>>horizon dns)? For that matter, let me be even more blunt:
>> I don't think that real DNS is being given enough attention altogether
>>in home settings, and until that happens we'll
>Agreed.   I'm delighted to hear that Simon has a hack in dnamasq that
>addresses this problem in a dual-stack environment, but I want to have a
>serious conversation somewhere about how to address the problem on the
>v6-only homenet.
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Feb 2013 13:12:18 -0500

> I thought mdnsext was supposed to handle this now?  Still agree it should

The question is whether this working group should just decide, sight-unseen, that an mdnsext solution will be good, or whether there are other solutions worth exploring.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 24 Feb 2013 10:27:20 -0800

> protocols/applications must still require the use of the same.
Practically speaking, iirc they have to some challenges to make their 
toolchain work across more than one subnet.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 24 Feb 2013 23:45:13 +0000

I believe this is accurate.

-----Original Message-----
From: Joel Jaeggli <[email-masked]>
Date: Sunday, February 24, 2013 10:27 AM
To: John Jason Brzozowski <[email-masked]>, Michael
Thomas <[email-masked]>
Cc: Michael Richardson <[email-masked]>, Mark Townsley
<[email-masked]>, Dave Taht <[email-masked]>, Jari Arkko
<[email-masked]>, "[email-masked] Group" <[email-masked]>, David
Lamparter <[email-masked]>, Lorenzo Colitti <[email-masked]>
Subject: Re: [homenet] NPTv6-only home networks

>>>>discoverable

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Feb 2013 23:00:18 -0500

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:
    >> I thought mdnsext was supposed to handle this now?  Still agree
    >> it should be covered some where.

    Ted> The question is whether this working group should just decide,
    Ted> sight-unseen, that an mdnsext solution will be good, or whether
    Ted> there are other solutions worth exploring.

I believe that this group should write its' requirements down clearly
and depend/trust upon the IESG to enforce them on an mDNSext group.  

Of course, it isn't like that group is being chartered to meet on mars
or some other inaccessible place.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 25 Feb 2013 23:17:51 +0100

> would be very interesting!

We might as well toss in some ULAs as well. 

- Mark

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Feb 2013 22:53:57 +0000

On 25 Feb 2013, at 22:17, Mark Townsley <[email-masked]> wrote
> We might as well toss in some ULAs as well. 

That would be very useful. 

Renumbering tests have been run ten years ago, with good results for the network elements given there's no 'flag day', but not with ULAs in the mix.

So 'flash' renumbering with ULAs in place would be interesting.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2013 13:06:36 +0900

> We might as well toss in some ULAs as well.

Hmm. Do we know for sure that all clients properly depref ULAs below global
addresses (either because they follow RFC6724 instead of RFC3484, or
because they implement the longest prefix matching rule?) If not, some
clients might break.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Feb 2013 15:13:29 +1100

In message <CAKD1Yr2Hw1V_JHxvqh_BfzFAsMxe_SifvW_GW4J40X=[email-masked]>
> because they implement the longest prefix matching rule?) If not, some
 
Longest match works well enough 2001/2002 have 14 bits in common.
fc00 has no bits in common with 2001 or 2002.  I've been using ULA
PA addresses together at home for years without issue.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Feb 2013 13:39:51 +0900

> PA addresses together at home for years without issue.

Which is why I asked whether we know for sure that all clients implement
it. Do we?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Feb 2013 16:39:33 +1100

In message <[email-masked]>
> Which is why I asked whether we know for sure that all clients implement

Does it matter?  There will presumably be a ssid without all the
experimentation going to fallback to.  The only question is this a
opt-in or opt-out experiment?

Mark

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 03:39:26 -0300

Hi, Ted,

On 02/22/2013 04:44 PM, Ted Lemon wrote:
>> Right now, I don't think that sufficient energy is being given to
>> just one obvious problem: how does real DNS interact with prefix
>> delegation in the home (assuming that we don't want split horizon
>> dns)? For that matter, let me be even more blunt: I don't think
>> that real DNS is being given enough attention altogether in home
>> settings, and until that happens we'll just inherit all of the
>> awful hacks that are done with NATv4.
> 
> addresses this problem in a dual-stack environment, but I want to
> have a serious conversation somewhere about how to address the
> problem on the v6-only homenet.
> 

I've been lurking for the most time, so.. double-checking: essentially,
what you want is that you always keep DNS for nodes in the internal
network, and those entries remain up-to-date e.g. in the presence of
renumbering? (I guess dynamic updates by each client is not acceptable,
so there should be some kind of "proxy" doing the job for the local net,
right?)

If I got your problem statement right, I'd argue that there are,
essentially, two problems here:
1) Learning the IPv6 addresses in use
2) Updating the DNS accordingly

"1" is already solved by <http://www.si6networks.com/tools/ipv6mon>.
"2" could be an add-on to ipv6mon, that would do the DNS updates
according to the address changes.

If the above sounds sensible, I voulteer to:
1) Write the code that does what I've described above
2) Write an I-D that describes what I've done with the code. :-)

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Simon Kelley <[email-masked]>
Date: Tue, 26 Feb 2013 07:52:50 +0000

> so there should be some kind of "proxy" doing the job for the local net,

Dnsmasq handles this already in the "guess slaac-addresses" case. When a 
new prefix is added to the network, dnsmasq advertises it and  goes 
through the existing DHCPv4 leases and pings the new putative addresses, 
adding  any that respond as AAAA records.

I'm not sure that hosts using stateful DHCPv6 fare so well, not least 
because I don't really understand what is meant to happen in the DHCP 
protocol in such circumstances.

> 2) Updating the DNS accordingly

Dnsmasq does both of these for internal DNS, it's just an extension of 
what it has always done in IPv4 land. There's a new test release that 
does the same for external DNS, by acting as the authoritative server 
for a zone, and/or  providing zone transfer to other authoritative servers.

Simon.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 05:05:51 -0300

> protocol in such circumstances.

You mean in the circumstance of renumbering, or what?

> for a zone, and/or  providing zone transfer to other authoritative servers.

As noted in my previous email, I was trying to address the v6-only case,
and also tryng to come up with a general technique that would handle the
case of SLAAC with IIDs that do not embed MAC addresses.

Cheers

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Feb 2013 10:50:52 +0000

On 26/02/2013 06:39, Fernando Gont wrote:
...
> renumbering? (I guess dynamic updates by each client is not acceptable,

Why not? That's what Secure DDNS Update is intended for, isn't it?

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 08:04:47 -0300

On 02/26/2013 07:50 AM, Brian E Carpenter wrote:
> Why not? 

Because if it's acceptable, there's no problem to worry about? :-)

-- I guess the thing with dynamic updates is that it doesn't work with
"zero configuration" (unless one assumes that updates on a local network
could be allowed to be unauthenticated?)

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 07:19:58 -0500

> could be allowed to be unauthenticated?)

There are lots of ways to make dynamic update work on a local network that wouldn't be acceptable on an enterprise network.   For instance, you could just say "if someone sends an update from an IP address, and that update installs an AAAA record pointing to that IP address, allow it."   Or you could use the CGA-TSIG draft.   Or you could use stateful DHCPv6.   Or you could use stateless DHCPv6.

Homenets aren't zeroconf--there has to be a way, at a minimum, to communicate a prefix and a DNS server address.   This can be done with RA, or with RA+stateless DHCPv6, or with stateful DHCPv6.   So in a homenet we can expect that there _will_ be a mechanism that _could_ be made to work for setting up DNS; the questions are:

(1) Which ways do we support, if any?
(2) How do we resolve the question of who is the local DNS server?

As far as I can tell, this whole notion has been punted in favor of multi-subnet mDNS; my concern is that we are going to wind up with a new protocol that's a weird amalgam of mDNS and DNS but shares little code with existing implementations of either protocol/

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 11:21:49 -0300

On 02/26/2013 09:19 AM, Ted Lemon wrote:
> Homenets aren't zeroconf--there has to be a way, at a minimum, to
> communicate a prefix and a DNS server address.   This can be done
> with RA, or with RA+stateless DHCPv6, or with stateful DHCPv6.   So
> in a homenet we can expect that there _will_ be a mechanism that
> _could_ be made to work for setting up DNS; the questions are:
> 

Stupid question:
Can we enforce requirements on host implementations as a result of
homenet? (e.g., among all the nice pieces of DDNS, how many of them are
widely implemented? and if not widely implemented, can we push changes
in this area?)

If we cannot do that, but can spec functionality in, say, home routers,
then something along the lines of what I sketched in my previous email
might make more sense.

> (2) How do we resolve the question of who is the local DNS server?

You mean the authoritative DNS server for nodes in the local network?

> As far as I can tell, this whole notion has been punted in favor of
> multi-subnet mDNS; my concern is that we are going to wind up with a
> new protocol that's a weird amalgam of mDNS and DNS but shares little
> code with existing implementations of either protocol/ 

Since I was not involved in such discussions, just double-checking: I
guess the whole argument for DNS had to do with
* No need for authoritative servers?
* Availability of "local" zones, as opposed to global zones?
* Something (technical :-) ) else?

I think that it shouldn't be hard to come up with something to make DNS
work with local zones, without relying on multicast (and thus avoiding
the need to do mDNS). If there's interest in exploring this path, I
could give this some thought -- just checking the mDNS thing is not
casted into stone, such that I avoid wasting time unnecessarily...

Thanks!

Best regards,

---

From: Ray Bellis <[email-masked]>
Date: Tue, 26 Feb 2013 14:26:26 +0000

On 26 Feb 2013, at 14:21, Fernando Gont <[email-masked]> wrote:

> homenet?

We should avoid it wherever possible.

Ray

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Feb 2013 15:29:01 +0100

> We should avoid it wherever possible.

for service discovery that's pretty much unavoidable.

cheers,
Ole

---

From: Ray Bellis <[email-masked]>
Date: Tue, 26 Feb 2013 14:43:26 +0000

> for service discovery that's pretty much unavoidable.

That's true.  The charter does in fact acknowledge this:

"Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, ..."

Ray

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Feb 2013 06:48:44 -0800

> There are lots of ways to make dynamic update work on a local network that wouldn't be acceptable on an enterprise network.   For instance, you could just say "if someone sends an update from an IP…

What I've been rolling through my head is a host being able to claim a
a name in a namespace when it attaches to a network provable by possession
of an asymmetric key it generates. The host could update that name binding
at any time (eg, change the AAAA) just by signing the update with that key.
The DNS could age those name bindings to get rid of transient names (eg,
phones that come and go on your homenet).

The "trust model" here is the ability to get onto my homenet at all, I think.
That is, I have the password to an SSID. Maybe different SSID's have different
DNS subdomains like XXX.guest.myhomedomain.org.

How this lines up with other work, or whether it meets the myriad of other
requirements, I do not know. But it at least seems plausible to me for a
littleconf kind of deployment like a homenet.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Feb 2013 07:07:23 -0800

On 02/25/2013 11:52 PM, Simon Kelley wrote:
> Dnsmasq does both of these for internal DNS, it's just an extension of what it has always done in IPv4 land. There's a new test release that does the same for external DNS, by acting as the authoritative server for a zone, and/or  providing zone transfer to other authoritative servers.

I'm not understanding: what is the name that it associates with the address?
A synthesized one like ISP's often do with forward map addresses in their
dynamic pool?

What I've been wondering is whether a "reverse mdns" might be handy in
these kinds of situations. Ie, "here's an address, what do you want your name
to be?" There at least you might get a name that is a little less opaque.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 11:24:10 -0500

> then something along the lines of what I sketched in my previous email

I dont think it cuts that way.   If we specify a system for doing this, and it gets general support in home gateways, particularly if it's supported by at least some operating systems, then we will probably see more implementations follow the spec.   So we should choose the solution we want, not settle for something.

I don't mean to suggest that what you've proposed isn't a good solution; simply that we should prefer it because it's a better solution, if it is, not because it's more likely to see widespread deployment.   At this stage in the life of IPv4, SunOS didn't even have a built-in DNS resolver, and had determined that Yellow Pages was the way to do naming.   (NIS, for those of us still old enough to remember SunOS, but not old enough to remember YP.)

As for "not needing authoritative DNS in the homenet," I think we've generally agreed that we at least need it so we can publish names externally; the real question is how we arrange for that to happen.   I think if we need it at all, we might as well just use it, and not develop a new protocol suite to do homenet naming.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 11:26:37 -0500

> phones that come and go on your homenet).

Yup.

> DNS subdomains like XXX.guest.myhomedomain.org.

I think you could just say that the guest domain isn't published externally.

> littleconf kind of deployment like a homenet.

Yes.   The complexity comes in if we support multihoming, which is part of homenet's scope.   It seems obvious that the edge router should be the authoritative name server, but what if there are two edge routers?

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Feb 2013 08:43:17 -0800

> Yes.   The complexity comes in if we support multihoming, which is part of homenet's scope.   It seems obvious that the edge router should be the authoritative name server, but what if there are tw…

I think we should probably steer clear of "convenient place to host the repository"
from its actual routing function. That is, I don't think that it really matters whether
it's an edge router or not even though it's a likely place to put that functionality
since it's always on, etc, etc. Maybe what we really want is to replicate the name
database onto *all* capable devices and then elect an authoritative one? Ideally,
I should be able to toss one of my routers into the trash and install another one
and not have naming die until I configure something again.

Not sure how you'd deal with the glue records to do that though... i doubt you'd
want to be changing that in the root zones. Maybe a clever use of anycast?

Mike

---

From: Ray Hunter <[email-masked]>
Date: Tue, 26 Feb 2013 18:10:33 +0100

>> phones that come and go on your homenet).
Yes.
> I think you could just say that the guest domain isn't published externally.
Yes.
> Yes.   The complexity comes in if we support multihoming, which is part of homenet's scope.   It seems obvious that the edge router should be the authoritative name server
Agreed, for on-homenet resolution (to keep service when one Internet
connection is down).
> , but what if there are two edge routers?
>
Elect one to be authoritative: which needs a new protocol, plus some
really complex take-over mechanism on failure.

Or just update all CER's independently. Plus any off-homenet hosted
personal domain if you're fortunate enough have one.

Why not? What's fundamentally wrong with having n AAAA records for the
same machine name resolved in n different zones in n authoritative DNS
servers?

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 26 Feb 2013 17:27:46 +0000

-----Original Message-----
From: Ted Lemon <[email-masked]>
Date: Tuesday, February 26, 2013 8:24 AM
To: Fernando Gont <[email-masked]>
Cc: "[email-masked] Group" <[email-masked]>
Subject: Re: [homenet] NPTv6-only home networks

>I dont think it cuts that way.   If we specify a system for doing this,
>and it gets general support in home gateways, particularly if it's
>supported by at least some operating systems, then we will probably see
>more implementations follow the spec.   So we should choose the solution
>we want, not settle for something.
[jjmb] the train will depart regardless, now would be a good time to
ensure we have focused achievable goals and requirements.
>
>I don't mean to suggest that what you've proposed isn't a good solution;
>simply that we should prefer it because it's a better solution, if it is,
>not because it's more likely to see widespread deployment.   At this
>stage in the life of IPv4, SunOS didn't even have a built-in DNS
>resolver, and had determined that Yellow Pages was the way to do naming.
> (NIS, for those of us still old enough to remember SunOS, but not old
>enough to remember YP.)
[jjmb] we also need to consider that we may not arrive at something that
works for everyone.
>
>As for "not needing authoritative DNS in the homenet," I think we've
>generally agreed that we at least need it so we can publish names
>externally; the real question is how we arrange for that to happen.   I
>think if we need it at all, we might as well just use it, and not develop
>a new protocol suite to do homenet naming.
[jjmb] I thought there was some other working going on where this data
could be extracted from the CPE router?

---

From: Simon Kelley <[email-masked]>
Date: Tue, 26 Feb 2013 18:15:42 +0000

> A synthesized one like ISP's often do with forward map addresses in their

Either the name that the host provides in a DHCP hostname or FQDN 
option, or a name associated with the host in the dnsmasq configuration. 
Most DHCP clients provide the hostname in  their DHCP requests these 
days. Dnsmasq configuration allows associating a name with a MAC address 
or client-id.

Simon.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Feb 2013 10:21:54 -0800

On 02/26/2013 10:15 AM, Simon Kelley wrote:
> Either the name that the host provides in a DHCP hostname or FQDN option, or a name associated with the host in the dnsmasq configuration. Most DHCP clients provide the hostname in  their DHCP requests these days. Dnsmasq configuration allows associating a name with a MAC address or client-id.

Ah, ok. But that wouldn't work in a SLAAC environment unless it did a DHCP
INFORM, right? Hosts don't do that generally, right?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 13:30:18 -0500

On Feb 26, 2013, at 11:43 AM, Michael Thomas <[email-masked]> wrote:
> from its actual routing function. That is, I don't think that it really matters whether it's an edge router or not even though it's a likely place to put that functionality since it's always on, etc, etc. Maybe what we really want is to replicate the name database onto *all* capable devices and then elect an authoritative one? Ideally, I should be able to toss one of my routers into the trash and install another one and not have naming die until I configure something again.

The reason I suggest using the edge device is that it's easy for a device to tell that it's the edge device, and you don't want to have a bazillion different devices doing it because it's hairy and complicated, and almost certainly won't be gotten right in a lot of implementations.   There is a value to following expedience here, and not trying to be overly clever.   What you're describing is basically mDNS, except mDNS doesn't use elections—it just uses assertions.   If that's the right answer, then we don't need to talk about a DNS primary in the homenet at all.

But you do bring up a good point, which is that keeping this database alive across physical reconfiguration events is worthwhile.   But maybe you want to primary the zone at your ISP or some other external service, and secondary it on your edge devices.

> want to be changing that in the root zones. Maybe a clever use of anycast?

The glue records for the PTR zone need to be at your ISP, so that's really easy.   The glue records for the AAAA zone need to be updatable and the TTL quite short (there won't be many queries, so this is ok).   Either way, if you have a publicly visible forward zone it's going to be either a name server you set up on a server off your homenet, or it's going to be on a name server you're buying service from (like dyndns.org), or you have some kind of promise from your ISP that they won't renumber you without notice, and your domain is in a registry.   Or maybe the primary is on your homenet, but isn't one of the published nameservers for the zone, and the ones that are published are off-net at your ISP or at someplace like dyndns.org.

---

From: Simon Kelley <[email-masked]>
Date: Tue, 26 Feb 2013 18:33:12 +0000

On 26/02/13 18:21, Michael Thomas wrote:
>> option, or a name associated with the host in the dnsmasq
>> configuration. Most DHCP clients provide the hostname in  their DHCP
>> requests these days. Dnsmasq configuration allows associating a name
>> with a MAC address or client-id.
>

It works in a SLAAC environment where the host _also_ does DHCPv4, which 
is where we came in.......

Simon.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Feb 2013 09:27:23 -0800

> really complex take-over mechanism on failure.

Pardon my ignorance, but how does this happen in real life, and in
particular with anycast? Aren't all of the anycast reachable servers
authoritative as far as the outside world is concerned?

Mike

---

From: Ray Hunter <[email-masked]>
Date: Tue, 26 Feb 2013 21:24:19 +0100

> authoritative as far as the outside world is concerned?
As far as I can see, there are no existing off-the-shelf solutions
available that cover all homenet naming requirements.

Therefore to answer your question: it doesn't happen in real life today.

We're talking theoretical auto-config of DNS servers by some process.
Which would be new and require some sort of election protocol to see
which CER would become "the anointed one." That server would then have
to work out which zone(s) to serve, given multiple parent ISPs. Also if
it failed we'd have to start all over again.

Hence the alternative suggestion that all CERs could always become
authoritative DNS servers, each providing a zone delegated from their
respective parent ISP (or other DNS name service provider). We'd
probably then either have to suggest the end nodes update all the
servers present in the homenet actively with name->AAAA information via
registration every time they moved. Or perhaps more practically, get the
host to update a random CER somehow, and then work out some way of
mirroring the latest info between zones in the background between the
CERs, without needing a static master-slave relationship. That'd
probably also require some new stuff.

But I'd still rather look at the gap analysis to make DNS work (with new
autoconfig/mirroring stuff), than try to proxy mDNS over multiple
subnets in an arbitrary topology (messy), or extend mDNS to be
multi-subnet aware (completely new, and reliant on site-wide multicast),
or extend a stateless protocol like mDNS to update DNS for off-homenet
resolution.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Feb 2013 09:36:12 +1100

> widely implemented? and if not widely implemented, can we push changes

Windows and MacOS both support DDNS.  You have to turn the latter on.
Thats well over half of homenet boxes.
 
> You mean the authoritative DNS server for nodes in the local network?

You make a SOA query for the name you want to add.  You remove
labels until you get a SOA response (there are optimisations that
can be applied to make this quicker).  You lookup the NS RRset now
that you have the containing zone.  If the master server (see the
SOA record) is in the NS RRset you send to it otherwise you try all
the NS's until you get SUCCESS or REFUSED.  If you get NOTIMP you
move onto the next server.  When you have exhausted all the servers
you stop.

NOTIMP indicates that update / update forwarding is not supported/enabled.
REFUSED means you hit a acl.
SUCCESS means you update was accepted.

This is bog standard update processing.  It works with split namespaces.

If you are updating PTR records you look for CNAME records with the
initial SOA query in case RFC 2317 delegations are present and you
update the owner name of the PTR to match the target of the CNAME.
You then restart the process.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Feb 2013 09:45:11 +1100

> This is bog standard update processing.  It works with split namespaces.

Code to do the above has been part of libresolv/libbind since 1997.
nsupdate calls that code to do its work.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Feb 2013 11:33:42 +1100

In message <[email-masked]>, Ted Lemon writes:
> I dont think it cuts that way.   If we specify a system for doing this, and i
> t gets general support in home gateways, particularly if it's supported by at
>  least some operating systems, then we will probably see more implementations
>  follow the spec.   So we should choose the solution we want, not settle for 
> something.
> 
> I don't mean to suggest that what you've proposed isn't a good solution; simp
> ly that we should prefer it because it's a better solution, if it is, not bec
> ause it's more likely to see widespread deployment.   At this stage in the li
> fe of IPv4, SunOS didn't even have a built-in DNS resolver, and had determine
> d that Yellow Pages was the way to do naming.   (NIS, for those of us still o
> ld enough to remember SunOS, but not old enough to remember YP.)

SunOS always has a DNS resolver.  It was the BIND 4.8 code.  Whether
hostname lookups where configured to use it or not was another matter.

> As for "not needing authoritative DNS in the homenet," I think we've generall
> y agreed that we at least need it so we can publish names externally; the rea
> l question is how we arrange for that to happen.   I think if we need it at a
> ll, we might as well just use it, and not develop a new protocol suite to do 
> homenet naming.
>