Tim Chown <tjc@ecs.soton.ac.uk> writes:
Some details would be interesting...
As far as I can see, resistance only comes from the current adminstrator of ip6.int. Let me try to summarise the arguments brought forward. 1. Zone consistency. BM> as I stated these are gripes. the nut of the issue is that BM> RIPE is proposing to edit/change the zone data between BM> the 3ffe:: delegations as seen from ip6.int and ip6.arpa BM> This is fatally flawed, as some folks will get one set of BM> answers while others will get distinctly different answers BM> to the same questions, based on the age of the resolver that BM> is in their endsystems. AFAICS, the change that RIRs propose is to remove delegations to non-authoritative nameservers. How could this cause "distinctly different answers"? 2. TSIG BM> ) the zone transfers should be protected by TSIG. I have BM> not been able to successfully work with RIPE on getting BM> TSIGS in place. I have been able to do so with both APNIC BM> and ARIN. I've not had dealings w/ LATNIC yet. Some people expressed their lack of understanding why this issue would delay implementation, as they view it as a nice-to-have. A reply to this: BM> as I stated these are gripes. the nut of the issue is that BM> RIPE is proposing to edit/change the zone data between BM> the 3ffe:: delegations as seen from ip6.int and ip6.arpa 3. IPv6 transport capability BM> ) IPv6 transport capability. ARIN does not have v6 capability. BM> RIPE has only sporadically supported v6 although I hope BM> the current efforts will be stable. APNIC has had stable BM> v6 capability for several years now. LATNIC has v6 experise BM> but I've not been able to get closure on their operational BM> stance. However, RIPE has a nameserver with IPv6 transport, while ns.apnic.net does not. One ip6.arpa server does have IPv6 connectivity. The same answer as to (3) applies. 4. "Same nameserver" issue BM> ) previous email to the 6bone list have suggested that BM> the same servers be used for both e.f.f.3.ip6.int and e.f.f.3.ip6.arpa BM> and I think this is a sound stratagy. So this means e.f.f.3.ip6.arpa would be delegated from the RIRs back to those nameservers. What advantage does this bring over a direct delegation from ip6.arpa, as long as the (active) delegations are the same? In particular the IPv6 transport issue would not be improved by an additional query layer. BM> So what I proposed to Andrei to take back to the RIRs was the BM> following: BM> BM> Recognise that the data published for 3ffe:: should be identical BM> regardless of anchorpoint. See above, (1) BM> Plan for an active migration plan BM> from industry/user nameservers to RIR nameservers for this delegation, What is meant by this? BM> based on the capability of the RIRs to support native IPv6 and BM> TSIG. See above (2) and (3). It's generally not understood in the community why this should delay delegation, instead of being an issue tackled later. BM> I've not heard back from Andrei or anyone else on this proposal. To me this sounds like a proposal how this can be delayed further, not how it can be implemented quickly. BM> I intend to work with the RIRs, starting with APNIC, to migrate BM> the 3ffe:: zone to RIR servers. It seems that the community strongly prefers the "do it NOW as it is, and make improvements later" approach. Robert