Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
Havard Eidnes wrote: >> Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it occured >> to me that the automatic reverse that >> draft-ietf-homenet-naming-architecture-dhc-options could enable >> better/simpler RFC2317 delegation for IPv4 subnets. >> >> My experience is that some of the pushback for doing 2317 is that there is >> sane way to automate it, and too many confusing ways to do it. >> >> So, I wrote: >> https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/ >> >> which basically says to point the CNAMEs into the IPv6 delegation that is >> "already" (will have been) being done. > The actual convention to use isn't really specified by 2317, only > a few examples are given. This one should work just as well as > any other convention, and if this makes it easier to use, I'm all > for it. Yes, the lack of a convention in 2317 was something that I noticed, and thought wait... what if we adopted *this* convention. (I see no point in proceeding with this document until the homenet documents are in RFC editor Q. Of course, as there are no IANA actions, and it's just a update to a convention, it could be implemented now) Tim Wicinski wrote: > Some time back Tony Finch proposed a 2317bis - > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00 > which the WG adopted but died for lack of interest. > It would be useful to revise this document Thank you for the pointer. It got enough interest to get adopted... the document looks like it could just be WGLC'ed. My suggest convention into the ip6.arpa tree could be combined in, and probably the first-last convention could be also be used. (and it sounds like Vixie thinks the document should/could go ahead) signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
On Thu, Dec 8, 2022 at 18:52, Tim Wicinski wrote: > Some time back Tony Finch proposed a 2317bis - > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00 > which the WG adopted but died for lack of interest. > > It would be useful to revise this document I could help with its rejuvenation, if that seems useful. I have certainly given lots of answers like Håvard's over the years and it would be nice to have a short cut to point to! Joe >>___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
i consider every example in that draft to be implied by the current 2317, and all are in wide use. it's a better-written document, though lacking coverage of some common use cases such as comcast's delegation to my house of a /24. ;; ANSWER SECTION: 1.150.104.24.in-addr.arpa. 3600 IN CNAME 1.0-255.150.104.24.in-addr.arpa. 1.0-255.150.104.24.in-addr.arpa. 3600 IN PTRinternal.gw1.rits.tisf.net. the /24 and /16 subdelegation cases follow directly from 2317's claims, even though i had to have this told to me by comcast at the time before i could see that. i sort of regret $GENERATE, it would be better if the zone did not have to be macro-expanded in this way before it could be axfr'd (or ixfr'd). if i had it to do over again i'd have proposed some kind of RR-encoded metadata to show the desired $GENERATE-like effect. but let's not take that on right now, ok? so: Tim Wicinski wrote on 2022-12-08 09:52: Some time back Tony Finch proposed a 2317bis - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00 which the WG adopted but died for lack of interest. It would be useful to revise this document tim +1, and i'll commit to reviewing it. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
Some time back Tony Finch proposed a 2317bis - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00 which the WG adopted but died for lack of interest. It would be useful to revise this document tim On Thu, Dec 8, 2022 at 5:14 AM Havard Eidnes wrote: > > Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it > occured > > to me that the automatic reverse that > > draft-ietf-homenet-naming-architecture-dhc-options could enable > > better/simpler RFC2317 delegation for IPv4 subnets. > > > > My experience is that some of the pushback for doing 2317 is that there > is > > sane way to automate it, and too many confusing ways to do it. > > > > So, I wrote: > > > https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/ > > > > which basically says to point the CNAMEs into the IPv6 delegation that is > > "already" (will have been) being done. > > The actual convention to use isn't really specified by 2317, only > a few examples are given. This one should work just as well as > any other convention, and if this makes it easier to use, I'm all > for it. > > Best regards, > > - Håvard > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
> Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it occured > to me that the automatic reverse that > draft-ietf-homenet-naming-architecture-dhc-options could enable > better/simpler RFC2317 delegation for IPv4 subnets. > > My experience is that some of the pushback for doing 2317 is that there is > sane way to automate it, and too many confusing ways to do it. > > So, I wrote: > https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/ > > which basically says to point the CNAMEs into the IPv6 delegation that is > "already" (will have been) being done. The actual convention to use isn't really specified by 2317, only a few examples are given. This one should work just as well as any other convention, and if this makes it easier to use, I'm all for it. Best regards, - Håvard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
