Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org> wrote:
    > These two sentences I think show the core of my lack of understanding.
    > Let's say I want to put my sauna on my public home net so I can access it
    > remotely and turn it on before I get home?

    > Is this envisioned as a goal of the homenet architecture?

You say, "homenet architecture", but our document is not the homenet 
architecture.
It's about the homenet naming architecture, and I'm sorry to be pedantic, but
the subtle difference includes a whole bunch of possible sins.
I have no idea if your sauna can be remotely controlled, or if if your home
router will let the traffic through, and it's not the job of this document to
standardize either of those things.

So, let's take a simpler version of this:

Your sauna can connect to an IRC server to tell you about it's temperature,
and the number of people currently in it.  But, IRC being what it is, it
would like to have a valid reverse name, and for that reverse name to match
the forward name before it will let you in.

    > Is it envisioned that this would be done by talking to the device, using a
    > name served by the "homenet public zone" ?

No, your sauna would not be involved at all.

    > If so, can I determine the name of this zone, or is it only CPE
    > auto-generated?

You would inform your CPE to please publish the IP address of your sauna
under a name that you decide.  How your CPE does this is not the concern of
the specification, but here are some ideas:
  * CPE identifies your sauna by MAC address, publishes the IPv6 that the NCE
    says is associated with it.
  * CPE identifies your sauna by mDNS name
  * you have told your CPE to give the sauna a specific IPv6 via DHCPv6, and
    it publishes that
  * something else

    > If I can determine the name, I am confused how this all would hook into
    > existing DNS infrastructure. It could be in my personal subdomain, a 
custom
    > generic domain in .com ?

You could have obtained a domain, yes, perhaps in .com, for your CPE.
"paulshome.nohat.ca" if you desire.

We suggest, non-normatively in Appendix C of a JSON blob that could be copy
and pasted from your domain provider/DOI to your CPE in order to configure
everything.  We imagine flows where this actually all happens via browser/OAUTH2
flow, but that's not a normative part of the specification.

Your CPE could have been provisioned with a name (probably ugly) by the maker
of the CPE device.  I have been involved in two proofs of concept for this.
The ISP that provided the CPE to you, or some other party that sold you service.

    > Then we get to my sauna device. It calls itself "tylo". How does this end
    > up as a FQDN in the homenet public zone ? How does my home end up being
    > able to query for it?
    > How do the queries go when not at home?

All of this is really in the document.
1) How your CPE publishes the name tylo is up to the CPE.

2) the CPE is authoriative for the homenet public zone

3) the CPE tells the Domain Outsourcing Infrastructure (DOI) about the
   localtion of the zone, and the DOI does a DoX to transfer it. The DOI
   has some resilient infrastructure to publish things.  Whether it's
   ns1/ns2 on different subnets, or some multi-continent anycast system
   depends upon what you pay.

4) when you aren't at home, the queries go to the ns1/ns2 that the DNS
   has published.

5) When you are at home, we expect the CPE to answer authoritatively
   itself.  A well designed CPE would have cached the DS/NS/DNSKEY that leads
   to it's domain so that it can answer a secure chain even when the Internet
   connection is broken.

    > So I am guessing. The only known method for hostnames publishing their
    > names into a zone I know of is with Dynamic Updates on a local zone. But
    > perhaps what homenet
    > envisions is that I give my sauna a static IP and configure some webgui on
    > my CPE to add it to my "zone" ?

No, and the document explains why this is a non-starter.


--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

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

Reply via email to