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-ipv6.pdf).
> 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
Attachment:
signature.asc
Description: This is a digitally signed message part