I thought about it and re-read what we wrote in 3901. 3901 talks about servers that need to deal with other parties: recursive resolvers and zone servers. It provides guidelines for the stability of entire DNS system.
In the particular case of the communication between the CPE and the ISP DNS recursive resolver, the two parties are within the same administrative authority. Thus, the need to make a BCP is much lower. This can be seen as simply an implementation issue. In other words, there are other solutions that could be used, for example a translation of the DNS packets from IPv4 to IPv6. Such a translation may or may not be optimal, but it would work and, more importantly, would not break the DNS resolution and would have no impact on the stability of the DNS system as a whole. As such, I¹m not convinced we should re-open 3901 for this purpose. Alain. On 11/3/15, 12:37 AM, "DNSOP on behalf of Mark Andrews" <[email protected] on behalf of [email protected]> wrote: > >Also perhaps we should be looking at RFC3901bis. Alain, Johan are you >interested? > >Mark > >In message <[email protected]>, Mark Andrews >writes: >> >> The simplest way to force this is for the ISP to only supply IPv6 >> recursive recursive servers to the CPE where 464XLAT / MAP* / DS-Lite >> is in use. Also if a DUID is presented over DHCPv4 (RFC 4361) don't >> return nameservers. The CPE device should be getting nameservers >> via RA/DHCPv6 in this case. >> >> The CPE at this point can only advertise it's own addresses IPv4 >> address or manually configured addresses. >> >> Iterative servers should prefer IPv6. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: [email protected] >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: [email protected] > >_______________________________________________ >DNSOP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dnsop
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
