vixie> Indeed not. We currently have to maintain a large and complex vixie> distributed registry of ipv4 ptr patterns which are meaningless vixie> and must therefore be filtered out before making policy decisions vixie> about the presence/absence and match/doesn't of a ptr record and vixie> it's associated a record.
You are already doing this, correct? Not good, has pain, but at least in place? And if I used a generation method for v6 that exactly matched v4, I'd just get caught in exactly the same filters, right? I know you want to make things better but does adding v6 records with the same format make things worse or just no better? If the current v4 is so fragile, it will break at any minute, you're already at risk. If what I produce in v6 adds no new checks, it should add no new risks; only the risk you have in v4 already. vixie> V6 should attempt to be better than v4 in this regard. In fact v4 vixie> should attempt to improve in this regard. It's a nice thought. But considering how little we've converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't even start on how many IPv6 transition techs there are), any consensus on "better" is going to be a fascinating trick. I have already mentioned that you and others are interested in some PTR usage solution that is better for both v4 and v6. And having actual real data on what is using PTRs in v4 and how as a second draft. I'd love to have real data to make an informed choice. I'm just suggesting that doing so is two drafts and significant effort on their own. paul> Functional at high cost and risking complexity collapse every day paul> and twice on Sunday is not a status quo to love, not to copy from paul> v4 to v6. And what's the plan for v4 if collapse is imminent? Who's working on it? And I sure hope it isn't that v6 will just replace v4, if time is of the essence. Large providers, including my $DAYJOB, are already looking at what/where/how we should do PTRs in v6. Going back to management and saying that we need to completely redo v4 (which they view as already working) and do v6 in some complicated way isn't something they're going to buy into without solid business case for cost savings and/or new income stream. So far, I haven't heard anything like those, for this draft or in potential new drafts. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
