On Thu, 2004-07-22 at 12:11, Andrei Robachevsky wrote:
Jeroen, all, <SNIP>
We were discussing possible ways of ip6.int phaseout with other RIRs, and one approach was presented at the last RIPE meeting in May (http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-reverse-i...). It is a bit less radical than yours.
I noticed the presentation, but couldn't find the minutes as I wasn't there myself. And due to technical reasons on my behalf I couldn't check the webcast nor from the archive.
Description of the plan is attached.
Timing it out slowly seems a good idea but in an off-list discussion with some people the following example by Daniel Roesen, why a direct cut-off would be the best to do: 8<----------------- CustA gets 2001:db8:1000::/48 CustA installs reverse for 2001:db8:1000::/48 in the ip6.int tree CustA changes ISP and gets another /48 CustB gets 2001:db8:1000::/48 CustB installs reverse for 2001:db8:1000::/48 in the ip6.arpa tree Thus the ip6.int tree still points to the NS's from CustA. As CustA didn't remove those entries from their nameserver now the following happens: CustC didn't upgrade their resolvers CustC thus notices in it's logs that the reverses for 2001:db8:1000::/48 are from CustA CustD did upgrade their resolvers CustD thus notices in it's logs that the reverses for 2001:db8:1000::/48 are from CustB ----------------->8 Thus depending if you upgraded or not you will be getting different results, which could have effects on the It is thus better to have *NO* IP6.INT zone as then the reverses will revert back to IPv6 numbers which is consistent with the IP6.ARPA tree. Should this example be included in the draft or do we want to keep it short? Greets, Jeroen