[ipv6-wg@ripe.net] Re: Reverse delegation for 6bone address space in ip6.arpa
Petr, all, over the last months, the RIRs have developed a reasonably pragmatic procedure to basically mirror the reverse delegation entries under ip6.int into ip6.arpa. Today, we have a working prototype implementing this approach. Unfortunately, our proposal has not been received favourably by the current administrator of the 6bone reverse delegations. To satisfy the needs of our members, however, we are now discussing another way to provide this functionality in a different way, building on the experiences we have made during the Early Registrations Transfer (ERX) Project. We will coordinate this closely with the other RIRs during next week's APNIC meeting; we are obviously also keeping an eye on the 6bone developements as regards the registry transfer and phaseout proposals. Expect a progress report after that. regards, Axel
Axel, thank you for the comments. Axel Pawlik <axel.pawlik@ripe.net> writes:
over the last months, the RIRs have developed a reasonably pragmatic procedure to basically mirror the reverse delegation entries under ip6.int into ip6.arpa. Today, we have a working prototype implementing this approach. Unfortunately, our proposal has not been received favourably by the current administrator of the 6bone reverse delegations.
Could you please solicit a public statment of his on this? It seems to me that there has been enough secret delay policy going on. How quickly could you implement the delegation if he agrees? The arguments on the 6bone ML against the RIPE proposal don't seem convincing. Allegedly RIRs propose to change the e.f.f.3.ip6.int zone when copying to to .ip6.arpa. Of which nature are those changes? I could only find removal of non-authoritative delegations. Robert
On Thu, Feb 20, 2003 at 09:28:26PM +0000, Robert Kiessling wrote:
Allegedly RIRs propose to change the e.f.f.3.ip6.int zone when copying to to .ip6.arpa. Of which nature are those changes? I could only find removal of non-authoritative delegations.
Some details would be interesting... I think most end user just want functionality now. The smoke and mirrors are not some important, so long as that functionality is there. Tim
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
participants (3)
-
Axel Pawlik -
Robert Kiessling -
Tim Chown