Hi Tim, > >> It may be useful to explicitly describe how a client using this approach > >> configures an address through which it can be reached from off the link it is > >> attached to, e.g, to ssh to it, use an HTTP method, etc. This is implied in > >> section 6.4 I think, but could be clearer. > > > > Strictly speaking it's the same approach as SLAAC. > > Would the following text address your concern: > > > > DHCPv6 servers that delegate prefixes can interface with Dynamic DNS > > infrastructure to automatically populate reverse DNS, similarly to > > what is described in section 2.5.2 of RFC [RFC8501]. Networks that > > also wish to populate forward DNS cannot do so automatically based > > only on DHCPv6 prefix delegation transactions, but they can do so in > > other ways, such as by supporting DHCPv6 address registration as > > described in [I-D.ietf-dhc-addr-notification]. > > > > ? > > Hmm, there’s the how the node configures an address on that interface, Ah ;) The thing is that the host behaviour is explicitly (and intentionally) out of scope. For me, as a network administrator, it doesn't matter how exactly the client configures that address: my network design/topology would be the same. The client can be a RFC7084-type router (that's what happens when someone plugs a CPE to an access port), or use smth like rfc7278 - or smth else. Up to the client, the network routes thet whole prefix to that device, do whatever you want with it. >and then also the how that might be added to the DNS. I’m not sure either is stated explicitly at the moment. > > I recall ietf-dhc-addr-notification originally included DNS registration, but the current version removed that? Yes, the dhc-addr-notification doesn't say anything about DNS. What we are saying in this draft is that the administrator may use DHCP server logs to populate DNS, if they chose so. Or it could be a dynamic DNS software run on the device. -- Cheers, Jen Linkova -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
