Re: [homenet] NPTv6-only home networks

[Mark Townsley]

> 
> On 26 Feb 2013, at 14:21, Fernando Gont  wrote:
> 
>> Stupid question:
>> Can we enforce requirements on host implementations as a result of
>> homenet?

What I have referred to in our meetings as the Thaler Doctrine (TM), is that if 
we end up with a phased approach in homenet, the demarcation would be exactly 
along these lines. e.g., Phase 1 would do the best we can while requiring zero 
changes to hosts, while Phase 2 does some things even better than Phase 1, but 
requires host changes to support. 

- Mark
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Mark Andrews]

In message <8ab7df5e-8cb6-44d7-a04f-757d9e152...@fugue.com>, Ted Lemon writes:
> On Feb 26, 2013, at 9:21 AM, Fernando Gont  wrote:
> > 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.
> 
> 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.
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Mark Andrews]

In message <20130226223612.40b74301a...@drugs.dv.isc.org>, Mark Andrews writes:
> 
> In message <512cc4fd.2020...@si6networks.com>, Fernando Gont writes:
> > 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:
> > > 
> > > (1) Which ways do we support, if any? 
> > 
> > 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?)
> 
> Windows and MacOS both support DDNS.  You have to turn the latter on.
> Thats well over half of homenet boxes.
>  
> > 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?
> 
> 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.

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

> 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.
> 
> > > 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,
> > -- 
> > Fernando Gont
> > e-mail: ferna...@gont.com.ar || fg...@si6networks.com
> > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> > 
> > 
> > 
> > 
> > -- 
> > Fernando Gont
> > SI6 Networks
> > e-mail: fg...@si6networks.com
> > PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> > 
> > 
> > 
> > 
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Mark Andrews]

In message <512cc4fd.2020...@si6networks.com>, Fernando Gont writes:
> 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:
> > 
> > (1) Which ways do we support, if any? 
> 
> 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?)

Windows and MacOS both support DDNS.  You have to turn the latter on.
Thats well over half of homenet boxes.
 
> 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?

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.

> > 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,
> -- 
> Fernando Gont
> e-mail: ferna...@gont.com.ar || fg...@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Hunter]

Michael Thomas wrote:
> On 02/26/2013 09:10 AM, Ray Hunter wrote:
>>
>> , 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.
>
> 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
>
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-> 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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

On 02/26/2013 09:10 AM, Ray Hunter wrote:


, 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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 26/02/13 18:21, Michael Thomas wrote:

On 02/26/2013 10:15 AM, Simon Kelley wrote:

On 26/02/13 15:07, Michael Thomas wrote:

On 02/25/2013 11:52 PM, Simon Kelley wrote:



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



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?


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?


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



Simon.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 26, 2013, at 11:43 AM, Michael Thomas  wrote:
> 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.

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.

> 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?

The glue records for the PTR zone need to be at your ISP, so that's really 
easy.   The glue records for the  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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

On 02/26/2013 10:15 AM, Simon Kelley wrote:

On 26/02/13 15:07, Michael Thomas wrote:

On 02/25/2013 11:52 PM, Simon Kelley wrote:



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



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?


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 26/02/13 15:07, Michael Thomas wrote:

On 02/25/2013 11:52 PM, Simon Kelley wrote:



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



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?


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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

-Original Message-
From: Ted Lemon 
Date: Tuesday, February 26, 2013 8:24 AM
To: Fernando Gont 
Cc: "homenet@ietf.org Group" 
Subject: Re: [homenet] NPTv6-only home networks

>On Feb 26, 2013, at 9:21 AM, Fernando Gont  wrote:
>> 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.
>
>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?
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Hunter]

Ted Lemon wrote:
> On Feb 26, 2013, at 9:48 AM, Michael Thomas  wrote:
>> 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 ) 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).
>
> Yup.
Yes.
>> 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.
>
> I think you could just say that the guest domain isn't published externally.
Yes.
>> 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.
>
> 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  records for the
same machine name resolved in n different zones in n authoritative DNS
servers?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

On 02/26/2013 08:26 AM, Ted Lemon wrote:



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.

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?



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 26, 2013, at 9:48 AM, Michael Thomas  wrote:
> 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 ) 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).

Yup.

> 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.

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

> 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.

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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 26, 2013, at 9:21 AM, Fernando Gont  wrote:
> 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.

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

On 02/25/2013 11:52 PM, Simon Kelley wrote:



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



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

On 02/26/2013 04:19 AM, Ted Lemon wrote:

On Feb 26, 2013, at 6:04 AM, Fernando Gont  wrote:

-- 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?)

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  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.


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 ) 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Bellis]

On 26 Feb 2013, at 14:29, Ole Troan  wrote:

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ole Troan]

>> Stupid question:
>> Can we enforce requirements on host implementations as a result of
>> homenet?
> 
> We should avoid it wherever possible.

for service discovery that's pretty much unavoidable.

cheers,
Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Bellis]

On 26 Feb 2013, at 14:21, Fernando Gont  wrote:

> Stupid question:
> Can we enforce requirements on host implementations as a result of
> homenet?

We should avoid it wherever possible.

Ray

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Fernando Gont]

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:
> 
> (1) Which ways do we support, if any? 

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,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 26, 2013, at 6:04 AM, Fernando Gont  wrote:
> -- 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?)

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 
 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/
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Fernando Gont]

On 02/26/2013 07:50 AM, Brian E Carpenter wrote:
> On 26/02/2013 06:39, Fernando Gont wrote:
> ...
>> 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,
> 
> 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,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brian E Carpenter]

On 26/02/2013 06:39, Fernando Gont wrote:
...
> 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,

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

   Brian
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Fernando Gont]

On 02/26/2013 04:52 AM, Simon Kelley wrote:
>> 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?)
> 
> 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  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.

You mean in the circumstance of renumbering, or what?



>> 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
> 
> 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.

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
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Fernando Gont]

On 02/26/2013 04:43 AM, Simon Kelley wrote:
>> But.. if you're learning the IPv6 addresses based on the assumption that
>> they are the traditional SLAAC addresses (that embed IEEE identifiers),
>> you'd be missing IPv6 addresses of Windows nodes (which do not generate
>> IIDs according to traditional SLAAC), any nodes using CGAs, etc.
> 
> On my network, the Windows nodes use stateful DHCPv6. I don't see this
> technique as a universal panacea or something to necessarily rely on
> going forward, but it does make naming work
> _for_existing_deployed_systems. It works, for instance, with hundreds of
> millions of existing Android phones and tablets, 99.99% of which will
> never be upgraded.

Agreed. I was mostly thinking about the IPv6-only case, and also about a
more general technique that would still work with SLAAC when hte IIDs do
not include MAC addresses.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 26/02/13 06:39, Fernando Gont wrote:

Hi, Ted,

On 02/22/2013 04:44 PM, Ted Lemon wrote:

On Feb 22, 2013, at 10:01 AM, Michael Thomas  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.


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?


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?)


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  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.




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


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.





"1" is already solved by .
"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. :-)



Simon.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 26/02/13 06:14, Fernando Gont wrote:

Hi, Simon,

On 02/23/2013 03:02 PM, Simon Kelley wrote:

On 23/02/13 17:56, Teemu Savolainen wrote:

And this works with hosts that use IPv6 privacy addresses and not have
IIDs derived from MAC?


If they have only privacy addresses, it doesn't work. If they have both
a SLAAC address and a privacy address, and use the privacy address when
initiating connections (for privacy), but accept connections to the
SLAAC address, then it still works.


But.. if you're learning the IPv6 addresses based on the assumption that
they are the traditional SLAAC addresses (that embed IEEE identifiers),
you'd be missing IPv6 addresses of Windows nodes (which do not generate
IIDs according to traditional SLAAC), any nodes using CGAs, etc.


On my network, the Windows nodes use stateful DHCPv6. I don't see this 
technique as a universal panacea or something to necessarily rely on 
going forward, but it does make naming work 
_for_existing_deployed_systems. It works, for instance, with hundreds of 
millions of existing Android phones and tablets, 99.99% of which will 
never be upgraded.


Simon.




Cheers,



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Fernando Gont]

Hi, Ted,

On 02/22/2013 04:44 PM, Ted Lemon wrote:
> On Feb 22, 2013, at 10:01 AM, Michael Thomas  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.
> 
> 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?

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 .
"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: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Fernando Gont]

Hi, Simon,

On 02/23/2013 03:02 PM, Simon Kelley wrote:
> On 23/02/13 17:56, Teemu Savolainen wrote:
>> And this works with hosts that use IPv6 privacy addresses and not have
>> IIDs derived from MAC?
> 
> If they have only privacy addresses, it doesn't work. If they have both
> a SLAAC address and a privacy address, and use the privacy address when
> initiating connections (for privacy), but accept connections to the
> SLAAC address, then it still works.

But.. if you're learning the IPv6 addresses based on the assumption that
they are the traditional SLAAC addresses (that embed IEEE identifiers),
you'd be missing IPv6 addresses of Windows nodes (which do not generate
IIDs according to traditional SLAAC), any nodes using CGAs, etc.

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Richardson]

> "Ted" == Ted Lemon  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.

-- 
Michael Richardson , Sandelman Software Works 




pgpwWHse8VWOJ.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

I believe this is accurate.

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







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

>On 2/24/13 9:41 AM, Brzozowski, John wrote:
>> 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.
>Practically speaking, iirc they have to some challenges to make their
>toolchain work across more than one subnet.
>>
>>
>> -Original Message-
>> From: Michael Thomas 
>> Date: Friday, February 22, 2013 7:24 AM
>> To: Joel Jaeggli 
>> Cc: Lorenzo Colitti , Michael Richardson
>> , Mark Townsley , Dave Taht
>> , Jari Arkko , John Jason
>> Brzozowski , "homenet@ietf.org Group"
>> , David Lamparter 
>> Subject: Re: [homenet] NPTv6-only home networks
>>
>>> joel jaeggli wrote:
>>>> On 2/21/13 7:04 PM, 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.
>>> 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
>>
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[joel jaeggli]

On 2/24/13 9:41 AM, Brzozowski, John wrote:

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.
Practically speaking, iirc they have to some challenges to make their 
toolchain work across more than one subnet.



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


joel jaeggli wrote:

On 2/21/13 7:04 PM, 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.

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




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 24, 2013, at 12:31 PM, "Brzozowski, John" 
 wrote:
> I thought mdnsext was supposed to handle this now?  Still agree it should
> be covered some where.

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

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.

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: Ted Lemon 
Date: Friday, February 22, 2013 11:44 AM
To: Michael Thomas 
Cc: Michael Richardson , Mark Townsley
, Dave Taht , Jari Arkko
, John Jason Brzozowski
, "homenet@ietf.org Group"
, David Lamparter , Lorenzo Colitti

Subject: Re: [homenet] NPTv6-only home networks

>On Feb 22, 2013, at 10:01 AM, Michael Thomas  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.
>
>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?
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

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 
Date: Friday, February 22, 2013 7:24 AM
To: Joel Jaeggli 
Cc: Lorenzo Colitti , Michael Richardson
, Mark Townsley , Dave Taht
, Jari Arkko , John Jason
Brzozowski , "homenet@ietf.org Group"
, David Lamparter 
Subject: Re: [homenet] NPTv6-only home networks

>joel jaeggli wrote:
>> On 2/21/13 7:04 PM, 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.
>
>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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

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) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: Simon Kelley 
Date: Friday, February 22, 2013 5:00 AM
To: "homenet@ietf.org" 
Subject: Re: [homenet] NPTv6-only home networks

>On 22/02/13 12:30, Ted Lemon wrote:
>> On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti 
>> wrote:
>
>> 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.
>
>
>
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

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


-Original Message-
From: Ted Lemon 
Date: Friday, February 22, 2013 4:27 AM
To: Michael Thomas 
Cc: Michael Richardson , Mark Townsley
, Dave Taht , Jari Arkko
, John Jason Brzozowski
, "homenet@ietf.org Group"
, Lorenzo Colitti , David Lamparter

Subject: Re: [homenet] NPTv6-only home networks

>On Feb 21, 2013, at 10:45 PM, Michael Thomas  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.
>
>+1
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brzozowski, John]

>
>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?
[jjmb] yes and I agree with your points.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

Erik Kline wrote:

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.


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...



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Erik Kline]

> 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.

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...
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 23/02/13 23:38, Dave Taht wrote:


Simon Kelly took what we had in cerowrt, and improved it substantially,
however there is still some stuff that is less than desirable, notably,
the DNS TTL is presently set to 0 in the dnsmasq implementation


This isn't quite accurate. Replies with cached data from forwarded 
queries of course get the TTL from upstream, reduced by the time the 
data has been cached. Replies with 0 TTL are answers to queries from 
internal hosts (ie from hosts on the local net) where the data in also 
local (ie stuff from /etc/hosts, other configuration or DHCP leases). 
The rationale is that re-doing the query is very cheap for these hosts, 
and there is no other good value for TTL.


DHCP lease time is not a good value. My laptop can have a DHCP lease 
with days left to run on my wireless subnet: if I plug in the wired 
network port, the name will be transfered to the new lease on the wired 
subnet, and I don't want to wait for days for all the hosts on the net 
to catch up with the new address.


For queries _not_ from the internal hosts (i.e. the new auth 
functionality) the TTL in the replies currently defaults to 600, and is 
configurable. These replies are only ever local data, dnsmasq will never 
forward-upstream queries from the wider net, to avoid DNS amplification 
attacks.


Simon.



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 23, 2013, at 6:41 PM, Dave Taht  wrote:
> dnsmasq is now a full fledged replacement for radvd, and as it nas insight 
> into the lease time now, coming up with either a suggested minimum TTL or one 
> based on the current value of the lease seems like a good idea. Suggestions?

The lease time is something configured on the gateway.   It's not really 
related to the TTL, since the expectation is that the device will renew over 
and over, even if the lease time is short.   And if the device moves to a 
different location, it probably won't be able to register the same name, so a 
stale record won't be a major problem.

Personally I'd use a value of 3600; it doesn't give you a ton of caching, but 
that doesn't matter for a name that is almost never looked up by anyone.   
Caching google.com is really important.   Caching 
washing-machine.brattlegrad.fugue.com, not so much.

As for the document, if it's worth documenting, it's worth someone writing the 
document.   If you want the person who first suggested it to you to get credit, 
mention them in the acknowledges and wax poetic about the greatness of their 
contribution.   If you want to make sure that the work gets documented, write 
the document if they won't.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Dave Taht]

On Sat, Feb 23, 2013 at 3:38 PM, Dave Taht  wrote:

>
> dnsmasq is now a full fledged replacement for radvd, and as it as insight
> into the lease time now, coming up with either a suggested minimum TTL or
> one based on the least seems like a good idea. Suggestions?
>

Grumble. Remind me not to try to write important stuff on my phone.

dnsmasq is now a full fledged replacement for radvd, and as it nas insight
into the lease time now, coming up with either a suggested minimum TTL or
one based on the current value of the lease seems like a good idea.
Suggestions?




>
> Secondly, what ietf group would shepard the document?
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html




-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Dave Taht]

On Sat, Feb 23, 2013 at 3:26 PM, Ted Lemon  wrote:

> On Feb 23, 2013, at 3:12 PM, Teemu Savolainen 
> wrote:
> > I'll leave it for those whose idea this was:-)
>
> If you insist.   However, that assumes that they will write a document,
> which isn't always a safe assumption.
>

I am a big believer in running code and rough consensus.

We seem to have both at the moment...

As one of the inventors of the dhcpv4 to SLAAC naming technique (with evan
hunt), I'm glad to hear this.

However, someone else had come up with it independently and published it a
few months prior to us, and we'd have to track that person down in order to
write an ID.

Simon Kelly took what we had in cerowrt, and improved it substantially,
however there is still some stuff that is less than desirable, notably, the
DNS TTL is presently set to 0 in the dnsmasq implementation, and I tend to
think it should reflect the available lease time, or some larger number
than 0, in order to do more effective caching.

dnsmasq is now a full fledged replacement for radvd, and as it as insight
into the lease time now, coming up with either a suggested minimum TTL or
one based on the least seems like a good idea. Suggestions?

Secondly, what ietf group would shepard the document?

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 23, 2013, at 3:12 PM, Teemu Savolainen  wrote:
> I'll leave it for those whose idea this was:-)

If you insist.   However, that assumes that they will write a document, which 
isn't always a safe assumption.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Teemu Savolainen]

I'll leave it for those whose idea this was:-)

(And it lacks the IPv6-only aspect)
 On Feb 23, 2013 8:46 PM, "Ted Lemon"  wrote:

> On Feb 23, 2013, at 1:39 PM, Teemu Savolainen 
> wrote:
> > Good points, those clarify. Might be good idea to write I-D about:)
>
> You offering?   :)
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 23, 2013, at 1:39 PM, Teemu Savolainen  wrote:
> Good points, those clarify. Might be good idea to write I-D about:)

You offering?   :)


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Teemu Savolainen]

Good points, those clarify. Might be good idea to write I-D about:)

Thank you.
 On Feb 23, 2013 8:14 PM, "Ted Lemon"  wrote:

> On Feb 23, 2013, at 1:02 PM, Simon Kelley  wrote:
> > If they have only privacy addresses, it doesn't work. If they have both
> a SLAAC address and a privacy address, and use the privacy address when
> initiating connections (for privacy), but accept connections to the SLAAC
> address, then it still works.
>
> I would argue that if they have only privacy addresses, it _does_ work,
> because privacy addresses ought not to be published in the DNS.
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 23, 2013, at 1:02 PM, Simon Kelley  wrote:
> If they have only privacy addresses, it doesn't work. If they have both a 
> SLAAC address and a privacy address, and use the privacy address when 
> initiating connections (for privacy), but accept connections to the SLAAC 
> address, then it still works.

I would argue that if they have only privacy addresses, it _does_ work, because 
privacy addresses ought not to be published in the DNS.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 23/02/13 17:56, Teemu Savolainen wrote:

And this works with hosts that use IPv6 privacy addresses and not have
IIDs derived from MAC?


If they have only privacy addresses, it doesn't work. If they have both 
a SLAAC address and a privacy address, and use the privacy address when 
initiating connections (for privacy), but accept connections to the 
SLAAC address, then it still works.


Simon.




From: Simon Kelley <mailto:si...@thekelleys.org.uk>
Sent: ‎22.‎2.‎2013 17:54
To: Ted Lemon <mailto:mel...@fugue.com>
Cc: homenet@ietf.org <mailto:homenet@ietf.org>; David Lamparter
<mailto:equi...@diac24.net>
Subject: Re: [homenet] NPTv6-only home networks

On 22/02/13 14:50, Ted Lemon wrote:
 > On Feb 22, 2013, at 8:24 AM, Simon Kelley 
wrote:
 >> 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.
 >
 > 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  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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Teemu Savolainen]

And this works with hosts that use IPv6 privacy addresses and not have IIDs 
derived from MAC?

-Original Message-
From: "Simon Kelley" 
Sent: ‎22.‎2.‎2013 17:54
To: "Ted Lemon" 
Cc: "homenet@ietf.org" ; "David Lamparter" 

Subject: Re: [homenet] NPTv6-only home networks

On 22/02/13 14:50, Ted Lemon wrote:
> On Feb 22, 2013, at 8:24 AM, Simon Kelley  wrote:
>> 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.
> 
> 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  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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Richardson]

> "Erik" == Erik Kline  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 , Sandelman Software Works 




pgpGIoD278upV.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 22/02/13 19:48, Ted Lemon wrote:

On Feb 22, 2013, at 10:53 AM, Simon Kelley  wrote:

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.


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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 22, 2013, at 10:53 AM, Simon Kelley  wrote:
> 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.

That is _very_ cool.   Nice work!

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 22, 2013, at 10:01 AM, Michael Thomas  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.

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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 22/02/13 14:50, Ted Lemon wrote:
> On Feb 22, 2013, at 8:24 AM, Simon Kelley  wrote:
>> 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.
> 
> 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  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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[joel jaeggli]

On 2/22/13 7:24 AM, Michael Thomas wrote:

joel jaeggli wrote:

On 2/21/13 7:04 PM, 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.


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.
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.


Mike



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

joel jaeggli wrote:

On 2/21/13 7:04 PM, 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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

Ted Lemon wrote:

On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti  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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 22, 2013, at 8:24 AM, Simon Kelley  wrote:
> 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.

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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 22, 2013, at 7:49 AM, Ray Bellis  wrote:
> 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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 22/02/13 13:07, David Lamparter wrote:
> On Fri, Feb 22, 2013 at 01:00:48PM +, Simon Kelley wrote:
>> On 22/02/13 12:30, Ted Lemon wrote:
>>> On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti 
>>> wrote:
>>
>>> 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.
> 
> 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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[David Lamparter]

On Fri, Feb 22, 2013 at 01:00:48PM +, Simon Kelley wrote:
> On 22/02/13 12:30, Ted Lemon wrote:
> > On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti 
> > wrote:
> 
> > 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.

This only works with stateful DHCPv6 though?

-David
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Simon Kelley]

On 22/02/13 12:30, Ted Lemon wrote:
> On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti 
> wrote:

> 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.




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Bellis]

On 22 Feb 2013, at 12:37, Ted Lemon 
 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.



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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Bellis]

On 22 Feb 2013, at 03:45, Michael Thomas  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



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 22, 2013, at 7:27 AM, Ted Lemon  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.
> 
> +1

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti  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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 21, 2013, at 10:45 PM, Michael Thomas  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.

+1

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Brian E Carpenter]

On 22/02/2013 03:45, Michael Thomas wrote:
...
> Well, if one of the requirements is that I be able to control my washing
> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[joel jaeggli]

On 2/21/13 7:04 PM, Michael Thomas wrote:

Lorenzo Colitti wrote:
On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas > 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.


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.
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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Lorenzo Colitti]

On Fri, Feb 22, 2013 at 12:04 PM, Michael Thomas  wrote:

> 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.


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?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

Ted Lemon wrote:

On Feb 21, 2013, at 10:32 PM, David Lamparter  wrote:

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...


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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ted Lemon]

On Feb 21, 2013, at 10:32 PM, David Lamparter  wrote:
> 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...

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[David Lamparter]

On Thu, Feb 21, 2013 at 07:04:01PM -0800, Michael Thomas wrote:
> Lorenzo Colitti wrote:
> > On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas  > > 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?

[...snip..]

> 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.

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...]

> > 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.

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Michael Thomas]

Lorenzo Colitti wrote:
On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas > 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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet