Subject: Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

From: Tim Chown <[email-masked]>
Date: Thu, 5 May 2016 13:00:20 +0100

> On 25 Apr 2016, at 03:39, Ted Lemon <[email-masked]> wrote:
> 
> On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek <[email-masked] <mailto:[email-masked]>> wrote:
> > Juliusz, the problem is that existing home network devices that do
> > DNS-based service discovery do not support DNS update. They could, but
> > they don't, because we didn't define an easy way for them to do it.
> 
> I'd be grateful if you could expand on that.  Why can't we define a way
> for clients to do DDNS?
> 
> We can and should.   The problem is that we won't see that code ship in new devices anytime soon, so we still have to make mDNS work.

And this is why the dnssd WG is focused on making mDNS work on multi-subnet networks.

But Ted has raised the question of DNS Update there, and we agreed in BA that we’d accept a draft on issues around coexistence of mDNS and DNS Update.

> > Just 2136 isn't enfough, because there's no authentication scheme,
> 
> I don't understand this argument.  How is non-secured DDNS any less secure
> than mDNS?  What am I missing?
> 
> This is an implementation issue, not a security issue--sorry for not making that clear.   In order to preserve the same security characteristics that mDNS has, we have to ensure that the update actually originated on the local link, which requires a different sort of listener than is present in a typical DNS server.   And existing DNS servers typically don't have any way to support unauthenticated updates on a first-come, first-served basis, so if you allow unauthenticated updates, you don't have any way to avoid collisions.   Otherwise you are correct.   The answer is to write a document that describes how to do that, and if you read the homenet naming arch document, you can see that I actually sketched out a solution there, which I expect to go in a different document, likely in a different working group.

There are many worms in that can :)

> Oh, sure, we Poles are not quite as pessimistic as the Finns.  I'm
> actually of a divided mind here -- I rather like distributed solutions
> (hence prefer mDNS to DDNS) but dislike proxying.  Part of me just wishes
> we'd mandate site-local multicast and do mDNS over that
> 
> The problem with site-local multicast for mDNS is that multicast isn't a great solution even on the local wire when that wire is wireless.    And, you have to do modify the client anyway.

Indeed; this was discussed early on in the dnssd WG, and not considered for those reasons. 

> Furthermore, if you consider the mdns hybrid proxy stateless, then you can have a DNS server that is roughly that stateless too.   I think it provides better service continuity if you are willing to retain some state, but everything will still work even if you don't, just as the hybrid proxy does.

Agreed.

Tim

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 05 May 2016 14:37:26 +0200

>> We can and should.  The problem is that we won't see that code ship in
>> new devices anytime soon, so we still have to make mDNS work.

> And this is why the dnssd WG is focused on making mDNS work on

Is there something I can read on this particular subject?

-- Juliusz

---

From: Tim Chown <[email-masked]>
Date: Thu, 5 May 2016 13:54:23 +0000

Hi,

> On 5 May 2016, at 13:37, Juliusz Chroboczek <[email-masked]> wrote:
> 

The WG charter is at: https://datatracker.ietf.org/wg/dnssd/charter/. 
A thing to note is that both large enterprises and (small) homenets are in scope, one of which is managed, one of which isn’t.

The requirements are documented in RFC 7558, which was published last year.

The current hybrid proxy draft is at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03, and is likely to be pushed to the IESG after the next update, based on discussion at the BA meeting. 
Section 6 describes the current implementation status. 
The author is Stuart Cheshire, who also of course is an author of mDNS and DNS-SD.

A parallel DNS Push draft allows optimisation, see: https://tools.ietf.org/html/draft-ietf-dnssd-push-07
(This draft is being split into two parts after discussion at the BA meeting, one of which will be done in the dnsop WG)

Finally, Markus has written a homenet-oriented hybrid proxy draft: https://tools.ietf.org/html/draft-ietf-homenet-hybrid-proxy-zeroconf-02, which aims to handle the unmanaged use of hybrid proxy.

Tim

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 11 May 2016 16:01:35 +0200

Tim Chown wrote:
>> On 25 Apr 2016, at 03:39, Ted Lemon <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> We can and should.   The problem is that we won't see that code ship 
>> in new devices anytime soon, so we still have to make mDNS work.
>
That to me seems to be putting pragmatism before requirements.

I'm not entirely convinced by the dnssd work, and have said so on the 
relevant WG.
>
> But Ted has raised the question of DNS Update there, and we agreed in 
> BA that we’d accept a draft on issues around coexistence of mDNS and 
> DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the line, 
is it sensible to pull this into Homenet now?

Is that the intended question to be answered by that draft?
>> This is an implementation issue, not a security issue--sorry for not 
>> making that clear.   In order to preserve the same security 
>> characteristics that mDNS has, we have to ensure that the update 
>> actually originated on the local link, which requires a different 
>> sort of listener than is present in a typical DNS server.   And 
>> existing DNS servers typically don't have any way to support 
>> unauthenticated updates on a first-come, first-served basis, so if 
>> you allow unauthenticated updates, you don't have any way to avoid 
>> collisions.   Otherwise you are correct.   The answer is to write a 
>> document that describes how to do that, and if you read the homenet 
>> naming arch document, you can see that I actually sketched out a 
>> solution there, which I expect to go in a different document, likely 
>> in a different working group.
>
I understand that this is potentially a huge can of worms, but if no one 
opens it, it'll never get solved.

So my preference would be to write down what we want in Homenet (in the 
naming architecture document, in a technology-agnostic way), analyse the 
gaps against competing current technologies, and then see what people 
propose to close those gaps.

If multi-subnet mDNS comes out a clear winner, then I'll shut up.

But I'm not even convinced that the gaps are understood/ documented at 
this time.

>> The problem with site-local multicast for mDNS is that multicast 
>> isn't a great solution even on the local wire when that wire is 
>> wireless.    And, you have to do modify the client anyway.
>
>> Furthermore, if you consider the mdns hybrid proxy stateless, then 
>> you can have a DNS server that is roughly that stateless too.   I 
>> think it provides better service continuity if you are willing to 
>> retain some state, but everything will still work even if you don't, 
>> just as the hybrid proxy does.
>
> Agreed.
>
> Tim
>
>>
>> [email-masked] <mailto:[email-masked]>

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Tim Chown <[email-masked]>
Date: Wed, 11 May 2016 14:40:09 +0000

Hi Ray,

On 11 May 2016, at 15:01, Ray Hunter (v6ops) <[email-masked]<mailto:[email-masked]>> wrote:

Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

To an extent it is. The Bonjour protocols are much more widely implemented and deployed than DNS Update.

I'm not entirely convinced by the dnssd work, and have said so on the relevant WG.

Do you mean the need for it based on Bonjour, or the solution given we’re building on that?

Note that one requirement was that other SD protocols could be integrated into the hybrid proxy model. That’s still possible, but no one has expressed any interest as yet.

But Ted has raised the question of DNS Update there, and we agreed in BA that we’d accept a draft on issues around coexistence of mDNS and DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the line, is it sensible to pull this into Homenet now?

I think this is why Ted is doing what he is doing.  Homenet is a different environment - smaller and unmanaged, generally.

The question is what happens in environments where both might mix.  Well, that’s one question.  Ted offered to draft a -00 on that topic, in one of his spare moments ;)

There are many worms in that can :)
I understand that this is potentially a huge can of worms, but if no one opens it, it'll never get solved.

So my preference would be to write down what we want in Homenet (in the naming architecture document, in a technology-agnostic way), analyse the gaps against competing current technologies, and then see what people propose to close those gaps.

That sounds like a good start.

But I'm not even convinced that the gaps are understood/ documented at this time.

No, and I agree there. But that doesn’t preclude delivering the hybrid proxy model, which is certainly applicable in campus environments (and was in response in part to an educause petition), and for which Markus has presented a draft for how that model could work in homenets.

Tim

Agreed.

Tim

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

--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 11 May 2016 18:15:50 +0200

>>>> We can and should.   The problem is that we won't see that code 
>>>> ship in new devices anytime soon, so we still have to make mDNS work.
>>>
> To an extent it is. The Bonjour protocols are much more widely 
> implemented and deployed than DNS Update.
>
Yes. I've seen a lot of printers shipping with it, and it works great at 
that scale.

I've also seen enterprises working with fully integrated DNS, together 
with managed Windows Domain Controllers, at monster scale.

Homenet is somewhere in the middle: we have more complexity, but no 
"computer certificates" to fall back on.

> Do you mean the need for it based on Bonjour, or the solution given 
Both.

Bonjour is a great protocol for a flat L2 network.

Bonjour is not designed for L3 networks (no inherent hop count, nor loop 
protection), nor support for multiple/overlapping name spaces.

The Homenet architecture calls for administrative zones.

I may have a guest LAN.
I may have a printer LAN (that is shared with guests)
I may have a media server (which is not shared with guests)

The Homenet architecture calls for multiple upstream providers.

I may have an electricity provider who allows me some special log on via 
the power network to control home automation, or feed back from my solar 
panels. They may publish (private) names for use by contracted customers 
that are not available over the Internet. Yes, that could also be done 
over Internet, but a specialised "walled garden" could be so much more 
secure and less vulnerable to external disruption.

Bonjour is (roughly) based on Appletalk AFAIK. I've got nothing against 
Appletalk Phase II, so if Bonjour was extended to provide an equivalent 
function to Appletalk Phase II Zone Information Protocol = ZIP then I'd 
be happier. That would cover concerns on non-overlapping name spaces. 
And Appletalk NBP/ZIP resolution also prevents loops in routed networks.

Otherwise I struggle to map the Homenet requirements onto the solution.

[BTW for the record, I don't consider DNS "as-is today" a great 
contender either. So I'm not just bashing Bonjour by any means]

>
> Note that one requirement was that other SD protocols could be 
> integrated into the hybrid proxy model. That’s still possible, but no 
> one has expressed any interest as yet.
>
I don't like the hybrid proxy model either.

It promises the union of the problems and intersection of the functionality.

Proxying flies in the face of the trend of smart devices and dumb networks.

If you get any device that bypasses, or misunderstands, the proxy 
topology, we could get very nasty name resolution loops [no inherent 
loop protection in Bonjour].

>>> But Ted has raised the question of DNS Update there, and we agreed 
>>> in BA that we’d accept a draft on issues around coexistence of mDNS 
>>> and DNS Update.
>> If "it" (multi-subnet mDNS) is going to cause more issues down the 
>> line, is it sensible to pull this into Homenet now?
>
> I think this is why Ted is doing what he is doing.  Homenet is a 
> different environment - smaller and unmanaged, generally.
>
> The question is what happens in environments where both might mix. 
>  Well, that’s one question.  Ted offered to draft a -00 on that topic, 
> in one of his spare moments ;)
>
That seems like a worthwhile draft.

>>>> This is an implementation issue, not a security issue--sorry for 
>>>> not making that clear.   In order to preserve the same security 
>>>> solution there, which I expect to go in a different document, 
>>>> likely in a different working group.
>>>
>> So my preference would be to write down what we want in Homenet (in 
>> the naming architecture document, in a technology-agnostic way), 
>> analyse the gaps against competing current technologies, and then see 
>> what people propose to close those gaps.
>
> No, and I agree there. But that doesn’t preclude delivering the hybrid 
> proxy model, which is certainly applicable in campus environments (and 
> was in response in part to an educause petition), and for which Markus 
> has presented a draft for how that model could work in homenets.
>
> Tim
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 18:29:49 +0200

> function to Appletalk Phase II Zone Information Protocol = ZIP then I'd be
> happier. That would cover concerns on non-overlapping name spaces. And
> Appletalk NBP/ZIP resolution also prevents loops in routed networks.

« The AppleTalk Zone Information Protocol (ZIP) manages the relationship
  between network numbers and zone names. »

While I could in principle go and pick a copy of Inside Appletalk at the
library, I'd be grateful if you could explain what you have in mind.

> I don't like the hybrid proxy model either.  It promises the union of
> the problems and intersection of the functionality.  Proxying flies in
> the face of the trend of smart devices and dumb networks.

Very well put.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 12:37:29 -0400

> > the face of the trend of smart devices and dumb networks.

Be that as it may, Homenet in general flies in the face of that trend.
And if you think about it, that trend isn't really a very smart trend,
because the burden it places on devices is extreme, and not all devices
have infinite resources to spend mapping the network and figuring out how
to publish their services on it.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 18:47:34 +0200

> Be that as it may, Homenet in general flies in the face of that trend.

Not sure.  If you look at HNCP, the only intelligence there is a bunch of
election algorithms (prefix assignment is just election with non-local
constraints, all the rest are just instances of two standard election
algorithms).

It's not as bad as it looks ;-)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 12:50:07 -0400

I tend to think of routing protocols and election protocols as
"intelligent", but perhaps you meant something different... :)

E.g., did you mean "stateful?"

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 19:00:10 +0200

> I tend to think of routing protocols and election protocols as "intelligent",
> but perhaps you meant something different... :)

> E.g., did you mean "stateful?"

No (HNCP manages quite a bit of hard state, unfortunately).  I think
I meant "able to interpret higher-layer data", but I'm no longer sure ;-)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 13:21:33 -0400

Hm, okay.   So perhaps you think of DNS data as being higher-layer than
routing data and numbering data?

On Wed, May 11, 2016 at 1:00 PM, Juliusz Chroboczek <
[email-masked]> wrote:

> "intelligent",

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 11 May 2016 19:57:08 +0200

> Ted Lemon <mailto:[email-masked]>
> 11 May 2016 18:37
>
>   And if you think about it, that trend isn't really a very smart 
> trend, because the burden it places on devices is extreme, and not all 
> devices have infinite resources to spend mapping the network and 
> figuring out how to publish their services on it.
>
But if we were to build a smart network from scratch, I also wouldn't 
start with proxies, nor maintain a distributed database in the hosts.

I'd start with letting the routers build a naming infra, together with 
defining a (simple) name registration protocol between host and on-link 
router(s) (together with conflict resolution to communicate "sorry, that 
names already taken")

And the starting point would then probably be HNCP + DNS to elect a max 
of 'n' authoritative name servers per homenet, where 'n' NS and AAAA 
records can fit it a single UDP packet.

So whether you prefer a "smart host" or "smart network" model, hybrid 
proxies seem a poor compromise.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 14:03:35 -0400

DNS update is pretty simple.   Any problem with using that?

I think you may be slightly conclusing "authoritative" and "primary."
There is no need to elect authoritative servers--just make them secondary
to the elected primary.   You can't have two primaries with stock
DNS--that's probably the biggest fly in the ointment.

The reason to have a hybrid proxy is because we have to support existing
devices.   Clearly it's not the right long-term solution, but we can't
force vendors to implement something new if they don't want to.

On Wed, May 11, 2016 at 1:57 PM, Ray Hunter (v6ops) <[email-masked]>
wrote:

>
>
> Ted Lemon <[email-masked]>
> 11 May 2016 18:37
>
> And the starting point would then probably be HNCP + DNS to elect a max of
> 'n' authoritative name servers per homenet, where 'n' NS and AAAA records
> can fit it a single UDP packet.
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 20:13:14 +0200

> So perhaps you think of DNS data as being higher-layer than routing data
> and numbering data?

Do you not?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 14:21:34 -0400

No.   Why are names different than numbers?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 20:57:28 +0200

> No. Why are names different than numbers?

I should be able to renumber without telling my users.

-- Juliusz

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 11 May 2016 21:29:09 +0200

> Juliusz Chroboczek <mailto:[email-masked]>
> 11 May 2016 18:29
I do happen to have a (yellowed) copy of "Inside Appletalk" on my 
bookshelf ;)

It would be new functionality to Bonjour, so strictly speaking it's out 
of scope for Homenet.

AFAIK (and I'm sure someone will keep me honest here) Appletalk strongly 
binds network numbers/cable ranges (prefixes in IPv6) to zones (logical 
groupings). Zone associations to network numbers/links are controlled by 
the Appletalk routers (not the hosts directly) and are associated with 
either a logical or physical link. The routing of name resolution 
requests to (extended) networks is based on zones. There can be multiple 
zones per network number, but the first zone is the "default zone" that 
hosts should use if they have no other preference. Host interfaces can 
only have a single network address and be a member of a single zone 
(although I've never actually seen that defined anywhere).

I leave it as a discussion point of whether that's a good model for 
Homenet, especially since IPv6 explicitly supports multiple prefixes per 
link and multiple addresses per interface per host.

Allowing a tight binding of IPv6 prefix <-> Homenet namespace zone could 
possibly work and simplify any solution for e.g. reverse resolution.

The key characteristics (that currently seem to be missing) would be:

1) a mechanism to route name resolution requests in an L3 network

2) a mechanism to prevent/ mitigate the effect of any (transient) loops 
in the name resolution infra (could be sub-function of 1)

3) a mechanism to advertise "zones" between Homenet routers.

4) a mechanism to advertise zones to hosts.

5) a field to indicate "zone membership" of a particular name/label to 
be used by hosts when advertising/resolving names.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 16:36:37 -0400

Spoken like a network administrator.   Of course, homenets have to be able
to renumber, but there is no "I" involved.   So the naming protocol has to
work with renumbering; ideally though intra-homenet communications would
use the homenet's ULA, and so renumbering wouldn't happen other than when
two homenets merged, and then it wouldn't be urgent.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 23:06:17 +0200

> So the naming protocol has to work with renumbering; ideally though
> intra-homenet communications would use the homenet's ULA,

That's not the point I'm making.  I mean that numbers are not user-visible,
while names obviously are.  That would seem to imply that naming is at
a higher level than either numbering or routing.  (I'm pretty sure there's
a paper by Clark on the subject somewhere.)

I'm curious why you think otherwise.

-- Juliusz

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2016 10:33:56 +1000

SIG(0) works fine for DDNS once you have a KEY record installed in
the DNS.

KEY can be installed on a "add if name does not exist basis" for
forward zone and add if TCP self (owner name is the matching
in-addr.arpa/ip6.arpa name of the TCP source address) is true for
the reverse zones.  This requires policy enforcement in the server
but is do able.  nameservers already have policy rules (e.g. tcp-self
has existed for years in named).  Adding more is not a hard thing
to do.

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 21:53:42 -0400

You don't even need SIG(0) to get the level of security that mDNS provides.
  And SIG(0) doesn't work right now, because it relies on an older version
of DNSSEC keys.   Remember the flag day?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2016 12:56:53 +1000

> of DNSSEC keys.   Remember the flag day?

DNSSEC depends on DNSKEY as of RFC 403[345]
SIG(0) depends on KEY.

The flag day seperated DNSSEC from other uses of KEY.  It did not
say "stop using KEY for everything" just for DNSSEC.

Mark

> --001a11c26b2ae5fabf05329b6f8a
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">You don&#39;t even need SIG(0) to get the level of securit=
> y that mDNS provides. =C2=A0 And SIG(0) doesn&#39;t work right now, because=
>  it relies on an older version of DNSSEC keys. =C2=A0 Remember the flag day=
> ?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Ma=
> y 11, 2016 at 8:33 PM, Mark Andrews <span dir=3D"ltr">&lt;<a href=3D"mailto=
> :[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><b=
> lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
> #ccc solid;padding-left:1ex"><br>
> SIG(0) works fine for DDNS once you have a KEY record installed in<br>
> the DNS.<br>
> <br>
> KEY can be installed on a &quot;add if name does not exist basis&quot; for<=
> br>
> forward zone and add if TCP self (owner name is the matching<br>
> in-addr.arpa/ip6.arpa name of the TCP source address) is true for<br>
> the reverse zones.=C2=A0 This requires policy enforcement in the server<br>
> but is do able.=C2=A0 nameservers already have policy rules (e.g. tcp-self<=
> br>
> has existed for years in named).=C2=A0 Adding more is not a hard thing<br>
> to do.<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> --<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </font></span></blockquote></div><br></div>
> 
> --001a11c26b2ae5fabf05329b6f8a--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2016 23:00:07 -0400

Hm. Ok, good news. Makes the job a wee bit easier.
On May 11, 2016 10:57 PM, "Mark Andrews" <[email-masked]> wrote:

Mark

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 12 May 2016 10:43:53 +0200

> 11 May 2016 20:03
Not with the update mechanism itself
>   There is no need to elect authoritative servers--just make them 
> secondary to the elected primary.   You can't have two primaries with 
> stock DNS--that's probably the biggest fly in the ointment.
>
Exactly.

The challenge is the Homenet requirement to support network segmentation 
and remerging.

We have multiple independent address spaces (ULA per router + GUA per 
provider), so why not multiple namespaces?

If a new router is added, a new ULA is added, together with associated 
namespace, and infra.
If a router is removed or dies, the ULA prefix expires, together with 
associated namespace and infra.

If a new ISP uplink is added, a new GUA is added, together with 
associated (upstream) (globally resolvable) namespace and infra.
If an ISP is removed or dies, the GUA expires, together with associated 
namespace and infra.

Then the namespace infra/ update server could be tightly bound to the 
device that delegates/creates it (either the homenet router, homenet 
border router, or the ISP infra)

I know people don't like DNS search lists, but they do work, and are 
widely supported. Or else a recursive resolver running on the local 
homenet router could handle the search work for the end hosts.

I also realize this creates a new challenge of how to update all of 
these various namespaces.

> The reason to have a hybrid proxy is because we have to support 
> existing devices.   Clearly it's not the right long-term solution, but 
> we can't force vendors to implement something new if they don't want to.
>
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 May 2016 15:10:55 +0200

If I'm reading you correctly, Ray, you're promoting unstable naming.  If
I have two routers called trurl and pirx in my network, then my printer
will becalled diablo630.pirx.home whe pirx is up, diablo630.trurl.home
when trurl is up, and either I reconfigure all of my hosts every time
I swap a router, or rely on the DNS search list being correct?

> provider),

No, we have a GUA per provider, and *optionally* a single ULA for the
whole Homenet:

      An HNCP router SHOULD create a ULA prefix if there is no other IPv6
      prefix with a preferred time greater than 0 in the network.  It MAY
      also do so if there are other delegated IPv6 prefixes, but none of
      which is locally generated [...]  In case multiple locally generated
      ULA prefixes are present, only the one published by the node with
      the greatest node identifier is kept

> If a new router is added, a new ULA is added,

No, that's not the case.

> If a router is removed or dies, the ULA prefix expires

Nope.  If a router dies, any ULA should remain stable, even if it's the
router who originally generated the ULA that dies:

   When a new ULA prefix is created, the prefix is selected [...] using
   the last non-deprecated ULA prefix

That's the whole point of using a ULA.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 12 May 2016 15:41:43 +0200

> 12 May 2016 15:10
> If I'm reading you correctly, Ray, you're promoting unstable naming.
Not promoting. Looking at the consequences.
>    If
actually I was thinking more along the lines of the printer being called

diablo630.default_zone.ula1.home (ULA1)

and

diablo630.default_zone.ula2.home (ULA2 if it exists)

and

diablo630.my_isp1.com (GUA1)

and

diablo630.my_isp2.net (GUA2)

simultaneously.

The DNSSL would indeed be updated automatically when the homenet 
autoconfigures, and advertised by RA.

The name registration and resolution for the various namespaces could 
run independently.
>        the greatest node identifier is kept
Thanks for that explanation.
>> If a new router is added, a new ULA is added,
What happens if that new router has been booted stand-alone (so it 
creates its own ULA), and then joins the Homenet by being plugged in, 
and has a higher node identifier?

Shouldn't this be a voting mechanism to retain the "most popular" 
existing ULA?
> That's the whole point of using a ULA.
Well even then you have the corner case of a split, stable operation, 
remerge, where one of the two ULA prefixes will disappear.

If the namespace relies in any way on the ULA, it'll change if the ULA 
changes.

If the namespace doesn't rely on the ULA, we'll likely get hit by the 
same (security) problems as mobile devices moving between disjoint 
.local networks.

Or else we have to manually configure a "Homenet root name"/ "Homenet 
identifier"?

Thoughts?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 May 2016 09:48:09 -0400

As long as the renumbering process is clean, there is no downside to
renumbering, and no reason to be careful about which ULA you ultimately
wind up with.

On Thu, May 12, 2016 at 9:41 AM, Ray Hunter (v6ops) <[email-masked]>
wrote:

>
> Juliusz Chroboczek <[email-masked]>
> 12 May 2016 15:10
>
> The name registration and resolution for the various namespaces could run
> independently.
>
> What happens if that new router has been booted stand-alone (so it creates
> its own ULA), and then joins the Homenet by being plugged in, and has a
> higher node identifier?
>
> Shouldn't this be a voting mechanism to retain the "most popular" existing
> ULA?
>
> If the namespace doesn't rely on the ULA, we'll likely get hit by the same
> (security) problems as mobile devices moving between disjoint .local
> networks.
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 May 2016 17:04:01 +0200

> its own ULA), and then joins the Homenet by being plugged in, and has
> a higher node identifier?

Each partition has at most one ULA.  When the partition heals, a single
ULA is retained.

> Shouldn't this be a voting mechanism to retain the "most popular" existing

If I read the intent correctly, HNCP assumes that partitions are an
exceptional occurrence, so when the partition heals an arbitrary ULA is
retained (the one with the higher id).

> remerge, where one of the two ULA prefixes will disappear.

Yes.

> Thoughts?

HNCP already contains provisions for naming -- see Sections 8 and 10.5 of
RFC 7788.  The procedures described there are fairly primitive, and don't
do anything to enforce stability.  Its main flaw is that it doesn't
provide a priority field, so there is no obvious way to prefer a human-
configured name to an automatically generated one.

If partitions are indeed a rare occurrence, then what is already in
RFC 7788 should be sufficient.  If you feel that this is not good enough,
we could doubtless devise something more refined.

-- Juliusz

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 13 May 2016 12:45:01 +0200

> 12 May 2016 15:48
> renumbering, and no reason to be careful about which ULA you 
> ultimately wind up with.
>
So are you suggesting the Homenet (internal) namespace should be 
independent of ULA address space?

In which case

1) how do we avoid the ".local" security problem where mobile devices 
are unable to distinguish whether they've actually moved to a different 
Homenet, or whether they've stayed still and their own Homenet has just 
renumbered.

Or else

2) Does the renumbering mechanism also trigger an automatic renaming too?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2016 09:40:40 -0400

If devices publish keys, then you can use those keys to make sure you are
still talking to them. And the dnssec validation of local names would also
work. Graceful renumbering should indeed result in DNS updates. Bear in
mind that this is graceful, so the old and new ULAs coexist for a while.
On May 13, 2016 06:45, "Ray Hunter (v6ops)" <[email-masked]> wrote:

In which case

1) how do we avoid the ".local" security problem where mobile devices are
unable to distinguish whether they've actually moved to a different
Homenet, or whether they've stayed still and their own Homenet has just
renumbered.

Or else

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Sat, 14 May 2016 14:51:44 +0200

Ted Lemon wrote:
>
> If devices publish keys, then you can use those keys to make sure you 
> are still talking to them. And the dnssec validation of local names 
> would also work. Graceful renumbering should indeed result in DNS 
> updates. Bear in mind that this is graceful, so the old and new ULAs 
> coexist for a while.
>

Sounds good.

So can we assume

1) a single ULA namespace for resolving all active ULAs, that will 
eventually converge to only containing RRs from a single ULA?

2) And that ULA namespace is disjoint from/completely independent of any 
GUA namespace?

> On May 13, 2016 06:45, "Ray Hunter (v6ops)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     As long as the renumbering process is clean, there is no downside
>>     to renumbering, and no reason to be careful about which ULA you
>>     ultimately wind up with.
>>
>     1) how do we avoid the ".local" security problem where mobile
>     devices are unable to distinguish whether they've actually moved
>     to a different Homenet, or whether they've stayed still and their
>     own Homenet has just renumbered.
>
>     Or else
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 May 2016 09:18:49 -0400

The only problem with that is that in the homenet ideally we'd like to have
local names signed and validatable via DNSSEC, and that requires that the
local namespace be global in scope, even if the names published in that
namespace are not.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 18 May 2016 11:03:28 +0200

> 14 May 2016 15:18
> The only problem with that is that in the homenet ideally we'd like to 
> have local names signed and validatable via DNSSEC, and that requires 
> that the local namespace be global in scope, even if the names 
> published in that namespace are not.
>
Not necessarily.

You only need global scope namespace if trust also needs to extend 
beyond Homenet.

If we're assuming that ULA will be used for on-Homenet communication 
streams (in the event of non-availability of GUA/ ISP uplink), then 
tying local names into the upstream global namespace is not strictly 
necessary.

So IMHO it would be just as acceptable to sign RRs for local names 
related to ULA address space with a locally-generated trust anchor 
(independent of the trust anchors installed on the Internet root servers).

Nodes and new routers would have to learn their local trust-anchor when 
connecting to the Homenet for the first time.

In other words, the local DNSSEC trust anchor identifies a Homenet. Not 
the ULA. Not an arbitrary label.

Otherwise we're going to need a globally-unique time-invariant label to 
identify this Homenet, that is also not based on the actual chosen ULA 
in use, which is not easy to generate.

>
> Ray Hunter (v6ops) <mailto:[email-masked]>
> 14 May 2016 14:51
>
>
> Ted Lemon wrote:
>>
> 2) And that ULA namespace is disjoint from/completely independent of 
> any GUA namespace?
>
>