[ipv6-wg@ripe.net] reverse, whois..
hi, why there is no "nameserver" records in inet6num? Also it would be useful to have reverse zones on ftp.ripe.net, like in-addr now is. Also, maybe could someone explain why dig -x 2001:778:: NS doesn't work? Is it my fault? best regards, Andrius
Andrius Kasparavicius wrote:
hi, why there is no "nameserver" records in inet6num?
There isn't one for inetnum's either.
Also it would be useful to have reverse zones on ftp.ripe.net, like in-addr now is.
I wonder where that could be useful for but then again there can be reasons ;)
Also, maybe could someone explain why dig -x 2001:778:: NS doesn't work?
;; QUESTION SECTION: ;\[x20010778000000000000000000000000/128].ip6.arpa. IN PTR] And bitlabels are moved to experimental and not supported. Use: $ ~/ip6_int.pl 2001:778::/32 8.7.7.0.1.0.0.2.ip6.int $ dig +trace 8.7.7.0.1.0.0.2.ip6.arpa NS <SNIP> $ dig +trace 8.7.7.0.1.0.0.2.ip6.int NS <SNIP> You might also want to try: $ whois -h whois.ripe.net 8.7.7.0.1.0.0.2.ip6.arpa $ whois -h whois.ripe.net 8.7.7.0.1.0.0.2.ip6.int Apparently no delegation for both, you might want to start mailing marvin the paranoid android :) Greets, Jeroen
Andrius Kasparavicius writes:
hi, why there is no "nameserver" records in inet6num? Also it would be useful to have reverse zones on ftp.ripe.net, like in-addr now is.
RIPE uses "domain" objects for this. Check out whois -h whois.ripe.net 0.8.7.7.0.1.0.0.2.ip6.arpa
Also, maybe could someone explain why dig -x 2001:778:: NS doesn't work? Is it my fault?
Not really. As Jeroen noticed, "dig -x" (and "host" too) still use the bit-string method of inverse mapping by default, but that method has been demoted to "Experimental" and is no longer seeing significant development/deployment. So you should always use the "-n" option to both "dig" and "host", when inverse-resolving IPv6 addresses, to enable the nibble-style method. Still you probably don't get what you want by doing "dig -n -x 2001:778:: NS", because you are probably looking for the inverse delegation for 2001:778::/32 (or /36), not 2001:778::/128. And I don't think dig/host can invert addresses with non-host (/128 or /32) prefix-lengths. Would be a nice addition though! (Ignoring the issue of non-nibble/byte-aligned prefixes for now.) Regards, -- Simon.
At 18:05 +0200 2/6/03, Simon Leinen wrote:
Andrius Kasparavicius writes:
hi, why there is no "nameserver" records in inet6num? Also it would be useful to have reverse zones on ftp.ripe.net, like in-addr now is.
RIPE uses "domain" objects for this. Check out
whois -h whois.ripe.net 0.8.7.7.0.1.0.0.2.ip6.arpa
Also, maybe could someone explain why dig -x 2001:778:: NS doesn't work? Is it my fault?
Not really. As Jeroen noticed, "dig -x" (and "host" too) still use the bit-string method of inverse mapping by default, but that method has been demoted to "Experimental" and is no longer seeing significant development/deployment.
What version of dig are you using? dig 8.3 certainly does not use bit-labels (and it composes the reverse query using ip6.arpa, not ip6.int).
So you should always use the "-n" option to both "dig" and "host", when inverse-resolving IPv6 addresses, to enable the nibble-style method.
Not necessary any more (-n does not exist in the current dig). Cheers, Joao Damas ISC
Joao Luis Silva Damas writes:
At 18:05 +0200 2/6/03, Simon Leinen wrote:
As Jeroen noticed, "dig -x" (and "host" too) still use the bit-string method of inverse mapping by default, but that method has been demoted to "Experimental" and is no longer seeing significant development/deployment.
What version of dig are you using?
The one from BIND 9.2.2. Apparently that's not new enough.
dig 8.3 certainly does not use bit-labels (and it composes the reverse query using ip6.arpa, not ip6.int).
The problem is that we use BIND 9 around here.
So you should always use the "-n" option to both "dig" and "host", when inverse-resolving IPv6 addresses, to enable the nibble-style method.
Not necessary any more (-n does not exist in the current dig).
Maybe in the current BIND8 dig, not in the current BIND9 dig. -- Simon.
You are right in that the dig that ships with BIND 9.2.2 works the way you described. This will change in 9.2.3 and 9.3.0. In the meantime you can use the dig from BIND 8 even if you run BIND 9.2.2 as the server. Joao At 21:56 +0200 5/6/03, Simon Leinen wrote:
Joao Luis Silva Damas writes:
At 18:05 +0200 2/6/03, Simon Leinen wrote:
As Jeroen noticed, "dig -x" (and "host" too) still use the bit-string method of inverse mapping by default, but that method has been demoted to "Experimental" and is no longer seeing significant development/deployment.
What version of dig are you using?
The one from BIND 9.2.2. Apparently that's not new enough.
dig 8.3 certainly does not use bit-labels (and it composes the reverse query using ip6.arpa, not ip6.int).
The problem is that we use BIND 9 around here.
So you should always use the "-n" option to both "dig" and "host", when inverse-resolving IPv6 addresses, to enable the nibble-style method.
Not necessary any more (-n does not exist in the current dig).
Maybe in the current BIND8 dig, not in the current BIND9 dig. -- Simon.
On Fri, 2003-06-06 at 16:55, Joao Luis Silva Damas wrote:
You are right in that the dig that ships with BIND 9.2.2 works the way you described. This will change in 9.2.3 and 9.3.0.
In the meantime you can use the dig from BIND 8 even if you run BIND 9.2.2 as the server.
I just stumbled over some strange behaviour regarding dig, version 8.3 (maybe a bug ?!?): The query 'dig ptr -x 2001:628::1' (2001:628::1 is or border router) produces the following result: ; <<>> DiG 8.3 <<>> ptr -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.0.1.0.0.2.ip6.arpa, type = PTR, class = IN ;; AUTHORITY SECTION: 0.0.2.6.0.1.0.0.2.ip6.arpa. 30M IN SOA scsnms.switch.ch. ipv6.switch.ch. ( 2003061300 ; serial 4H ; refresh 30M ; retry 5w6d16h ; expiry 30M ) ; minimum ;; Total query time: 28 msec ;; FROM: nocv6.cc.univie.ac.at to SERVER: default -- 131.130.1.11 ;; WHEN: Fri Jun 13 13:17:49 2003 ;; MSG SIZE sent: 90 rcvd: 147 Have a look at the _QUERY SECTION_, as you can see there is the 8 missing for .0.8.2.6. The behaviour is the same, regardless which address out of our prefix I use. If I query 'dig ptr 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa.' the answer is OK: ; <<>> DiG 8.3 <<>> ptr 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa. ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6 ;; QUERY SECTION: ;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa, type = PTR, class = IN ;; ANSWER SECTION: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN PTR wien6.v6.aco.net. ;; AUTHORITY SECTION: 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns5.v6.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns5.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns6.v6.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns6.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns-v6.ripe.net. ;; ADDITIONAL SECTION: ns5.v6.univie.ac.at. 19H IN AAAA 2001:628:402:1:204:acff:fede:2319 ns5.univie.ac.at. 19H IN A 193.171.255.77 ns6.v6.univie.ac.at. 19H IN AAAA 2001:628:402:1:60:8cff:fe2f:4794 ns6.univie.ac.at. 19H IN A 193.171.255.78 ns-v6.ripe.net. 1d19h8m53s IN A 193.0.0.193 ns-v6.ripe.net. 1d19h8m57s IN AAAA 2001:610:240:0:193::193 ;; Total query time: 5 msec ;; FROM: nocv6.cc.univie.ac.at to SERVER: default -- 131.130.1.11 ;; WHEN: Fri Jun 13 13:24:04 2003 ;; MSG SIZE sent: 90 rcvd: 364 Is this a known bug ??? I use the dig, which comes with FreeBSD 4.8. Thanks, best regards, Kurt -- Kurt Bauer <bauer@cc.univie.ac.at> Vienna University Computer Center - ACOnet - VIX Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: ++43 1 4277 - 14070 (Fax: - 9140) KB1970-RIPE
You are right, it seems to always turn the last nibble of the second quartet to 0, no matter what. We will have a look Joao At 15:27 +0200 13/6/03, Kurt Bauer wrote:
On Fri, 2003-06-06 at 16:55, Joao Luis Silva Damas wrote:
You are right in that the dig that ships with BIND 9.2.2 works the way you described. This will change in 9.2.3 and 9.3.0.
In the meantime you can use the dig from BIND 8 even if you run BIND 9.2.2 as the server.
I just stumbled over some strange behaviour regarding dig, version 8.3 (maybe a bug ?!?):
The query 'dig ptr -x 2001:628::1' (2001:628::1 is or border router) produces the following result: ; <<>> DiG 8.3 <<>> ptr -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.6.0.1.0.0.2.ip6.arpa, type = PTR, class = IN
;; AUTHORITY SECTION: 0.0.2.6.0.1.0.0.2.ip6.arpa. 30M IN SOA scsnms.switch.ch. ipv6.switch.ch. ( 2003061300 ; serial 4H ; refresh 30M ; retry 5w6d16h ; expiry 30M ) ; minimum
;; Total query time: 28 msec ;; FROM: nocv6.cc.univie.ac.at to SERVER: default -- 131.130.1.11 ;; WHEN: Fri Jun 13 13:17:49 2003 ;; MSG SIZE sent: 90 rcvd: 147
Have a look at the _QUERY SECTION_, as you can see there is the 8 missing for .0.8.2.6. The behaviour is the same, regardless which address out of our prefix I use.
If I query 'dig ptr 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa.' the answer is OK: ; <<>> DiG 8.3 <<>> ptr 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa. ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6 ;; QUERY SECTION: ;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa, type = PTR, class = IN
;; ANSWER SECTION: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN PTR wien6.v6.aco.net.
;; AUTHORITY SECTION: 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns5.v6.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns5.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns6.v6.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns6.univie.ac.at. 8.2.6.0.1.0.0.2.ip6.arpa. 9m55s IN NS ns-v6.ripe.net.
;; ADDITIONAL SECTION: ns5.v6.univie.ac.at. 19H IN AAAA 2001:628:402:1:204:acff:fede:2319 ns5.univie.ac.at. 19H IN A 193.171.255.77 ns6.v6.univie.ac.at. 19H IN AAAA 2001:628:402:1:60:8cff:fe2f:4794 ns6.univie.ac.at. 19H IN A 193.171.255.78 ns-v6.ripe.net. 1d19h8m53s IN A 193.0.0.193 ns-v6.ripe.net. 1d19h8m57s IN AAAA 2001:610:240:0:193::193
;; Total query time: 5 msec ;; FROM: nocv6.cc.univie.ac.at to SERVER: default -- 131.130.1.11 ;; WHEN: Fri Jun 13 13:24:04 2003 ;; MSG SIZE sent: 90 rcvd: 364
Is this a known bug ??? I use the dig, which comes with FreeBSD 4.8.
Thanks,
best regards, Kurt
-- Kurt Bauer <bauer@cc.univie.ac.at> Vienna University Computer Center - ACOnet - VIX Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: ++43 1 4277 - 14070 (Fax: - 9140) KB1970-RIPE
This is bug 1409 on the bugs list:
From 8.3.5
1409. [bug] dig: reverse6 computed a incorrect nibble string. It is fixed in 8.3.5 and later. Joao At 15:57 +0200 13/6/03, Joao Luis Silva Damas wrote:
You are right, it seems to always turn the last nibble of the second quartet to 0, no matter what.
We will have a look
Joao
Vienna University Computer Center - ACOnet - VIX Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: ++43 1 4277 - 14070 (Fax: - 9140) KB1970-RIPE
Hello, As you may have noticed "M", located at Tokyo was assigned 2001:0DC3::/32 from APNIC last week, with the status "ASSIGNED PORTABLE". Looking at http://www.root-servers.org, i see there are two root-servers located in the RIPE region that could get a /32 from RIPE, provided that RIPE would adopt the same policy than APNIC in this case: - "I" at Stockholm, Sweden; - "K" at London, England. Regarding the other 10 dns root servers, 2 of them already have IPv6 assignments from ARIN's microallocation pool ("F" and "H"), which is in fact a different approach. As we speak im getting around 400ms rtt to "H" and about 240 rtt to "F". Anybody (around Europe) is getting significantly better values? Any comments? Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 "Internet is just routes (125953/461), naming (millions) and... people!"
wow, last time I checked root servers(several weeks ago, they was unreacheble-not operational.. now looks great: F: 11 2001:500::1035 (2001:500::1035) 192.812 ms 192.25 ms 192.513 ms only one BGP path to 2001:500::/48 prefix ;( anyway it works! : H: unreachible, no BGP paths to 13 ASn, maybe /48 get's filtered? and what about anycast implementation for root servers? It would be great in perfomance, dunno in security & how stable it could be in attacs.. I'll try to add F to my bind root servers ;) Andrius On Tue, 24 Jun 2003, Carlos Friacas wrote:
Hello,
As you may have noticed "M", located at Tokyo was assigned 2001:0DC3::/32 from APNIC last week, with the status "ASSIGNED PORTABLE".
Looking at http://www.root-servers.org, i see there are two root-servers located in the RIPE region that could get a /32 from RIPE, provided that RIPE would adopt the same policy than APNIC in this case:
- "I" at Stockholm, Sweden; - "K" at London, England.
Regarding the other 10 dns root servers, 2 of them already have IPv6 assignments from ARIN's microallocation pool ("F" and "H"), which is in fact a different approach. As we speak im getting around 400ms rtt to "H" and about 240 rtt to "F". Anybody (around Europe) is getting significantly better values?
Any comments?
Regards,
./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
"Internet is just routes (125953/461), naming (millions) and... people!"
Andrius Kasparavicius wrote:
wow, last time I checked root servers(several weeks ago, they was unreacheble-not operational.. now looks great:
F: 11 2001:500::1035 (2001:500::1035) 192.812 ms 192.25 ms 192.513 ms
only one BGP path to 2001:500::/48 prefix ;( anyway it works! :
H: unreachible, no BGP paths to 13 ASn, maybe /48 get's filtered?
IMHO they should be filtered, it's not a TLA. Just give those *root*servers a /32 like the rest, saving on filtering headaches. Notez bien http://www.space.net/~gert/RIPE/ipv6-filters.html states: "In addition to this, inside 2001:500::/32, the lists permits /48s. This network block is the ARIN microallocation block, and ARIN is assigning /48s directly to end networks (like root name servers)." But still I don't like any 'specialties'... but that is my opinion ;) Btw 2001:1488::/32 CZ-NIC-20030620, I surely don't hope that is for a tld server because that is something entirely different. Rootservers need to be hardcoded, by IP into configs. TLD servers can get resolved (and thus changed) in those rootservers.
and what about anycast implementation for root servers? It would be great in perfomance, dunno in security & how stable it could be in attacs..
I'll try to add F to my bind root servers ;)
Btw why don't these servers have a AAAA record in DNS? $ host -t aaaa f.root-servers.org $ host -t aaaa h.root-servers.org Also what is the difference between root-servers.org and root-servers.net: $ host k.root-servers.org k.root-servers.org. has address 193.0.0.203 $ host k.root-servers.net k.root-servers.net. has address 193.0.14.129 Maybe someone can sync those? (SOA's cc:'d) I think .org is lagging behind btw as the .net version is the distributed K. And .net is pointed down from the root (.). Also note that K, and some others, are distributed is that going to happen for their IPv6 equivs too ? Greets, Jeroen
I'll try to add F to my bind root servers ;)
Btw why don't these servers have a AAAA record in DNS?
$ host -t aaaa f.root-servers.org $ host -t aaaa h.root-servers.org
well' it works fine.. anyway, my bind9 get's root zone via IPv6 from F. and then uses that zone(with ipv4-only) for other recursive queries.. I think while it is not a production(guaranted IPv6 transport, redundancy at IPv6 space.. & etc..) service, there can't be AAAA records. But I of course would like to.. :)
Also what is the difference between root-servers.org and root-servers.net:
$ host k.root-servers.org k.root-servers.org. has address 193.0.0.203 $ host k.root-servers.net k.root-servers.net. has address 193.0.14.129
IMO .net for operations .org for those operations reports/information best regards, Andrius
On Wed, 25 Jun 2003, Jeroen Massar wrote:
Andrius Kasparavicius wrote:
wow, last time I checked root servers(several weeks ago, they was unreacheble-not operational.. now looks great:
F: 11 2001:500::1035 (2001:500::1035) 192.812 ms 192.25 ms 192.513 ms
only one BGP path to 2001:500::/48 prefix ;( anyway it works! :
H: unreachible, no BGP paths to 13 ASn, maybe /48 get's filtered?
Hello,
IMHO they should be filtered, it's not a TLA. Just give those *root*servers a /32 like the rest, saving on filtering headaches. Notez bien http://www.space.net/~gert/RIPE/ipv6-filters.html states: "In addition to this, inside 2001:500::/32, the lists permits /48s. This network block is the ARIN microallocation block, and ARIN is assigning /48s directly to end networks (like root name servers)."
But still I don't like any 'specialties'... but that is my opinion ;)
ARIN's policy is different from APNIC and RIPE. Should we (RIPE) defend filtering according *only* to our regional policy? I personally dont think so.
Btw 2001:1488::/32 CZ-NIC-20030620, I surely don't hope that is for a tld server because that is something entirely different. Rootservers need to be hardcoded, by IP into configs. TLD servers can get resolved (and thus changed) in those rootservers.
Some people consider ccTLDs (like IXPs/NAPs and root-servers as "critical infrastructure"), some others dont. :-) (...)
Also note that K, and some others, are distributed is that going to happen for their IPv6 equivs too ?
Hope so. :-)
Greets, Jeroen
Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 "Internet is just routes (125953/461), naming (millions) and... people!"
Hi, On Tue, Jun 24, 2003 at 01:33:07PM +0100, Carlos Friacas wrote:
As you may have noticed "M", located at Tokyo was assigned 2001:0DC3::/32 from APNIC last week, with the status "ASSIGNED PORTABLE".
Looking at http://www.root-servers.org, i see there are two root-servers located in the RIPE region that could get a /32 from RIPE, provided that RIPE would adopt the same policy than APNIC in this case:
- "I" at Stockholm, Sweden; - "K" at London, England.
I don't see why RIPE would have to adopt any specific policy here? We *have* a "how to get IPv6 addresses for root name servers" policy, and it's already in place. I and K just have to apply for a block. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, 24 Jun 2003, Gert Doering wrote:
Hi,
On Tue, Jun 24, 2003 at 01:33:07PM +0100, Carlos Friacas wrote:
As you may have noticed "M", located at Tokyo was assigned 2001:0DC3::/32 from APNIC last week, with the status "ASSIGNED PORTABLE".
Looking at http://www.root-servers.org, i see there are two root-servers located in the RIPE region that could get a /32 from RIPE, provided that RIPE would adopt the same policy than APNIC in this case:
- "I" at Stockholm, Sweden; - "K" at London, England.
I don't see why RIPE would have to adopt any specific policy here?
As far as i read it (RIPE-233), the RIPE policy for these cases is similar to APNIC's.
We *have* a "how to get IPv6 addresses for root name servers" policy, and it's already in place. I and K just have to apply for a block.
That was the point where i wanted to reach :-) ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 "Internet is just routes (125953/461), naming (millions) and... people!"
Hi Carlos, Carlos Friacas wrote:
Hello,
As you may have noticed "M", located at Tokyo was assigned 2001:0DC3::/32 from APNIC last week, with the status "ASSIGNED PORTABLE".
Looking at http://www.root-servers.org, i see there are two root-servers located in the RIPE region that could get a /32 from RIPE, provided that RIPE would adopt the same policy than APNIC in this case:
There is an adopted policy in the RIPE region described in the document "IPv6 Addresses for Internet Root Servers in the RIPE Region" (http://www.ripe.net/ripe/docs/ipv6-rootservers.html). If any of the DNS root operators applies for the address space there are /32 reserved for them.
- "I" at Stockholm, Sweden; - "K" at London, England.
As for the K (being an operator of this server) we don't have definite plans for ipv6 deployment. Also there are different views on how ipv6 access should be provided to the root zone.
Regarding the other 10 dns root servers, 2 of them already have IPv6 assignments from ARIN's microallocation pool ("F" and "H"), which is in fact a different approach. As we speak im getting around 400ms rtt to "H" and about 240 rtt to "F". Anybody (around Europe) is getting significantly better values?
Any comments?
Regards,
./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
"Internet is just routes (125953/461), naming (millions) and... people!"
Regards, Andrei Robachevsky CTO, RIPE NCC
Hello again, On Tue, 24 Jun 2003, Andrei Robachevsky wrote:
Looking at http://www.root-servers.org, i see there are two root-servers located in the RIPE region that could get a /32 from RIPE, provided that RIPE would adopt the same policy than APNIC in this case:
There is an adopted policy in the RIPE region described in the document "IPv6 Addresses for Internet Root Servers in the RIPE Region" (http://www.ripe.net/ripe/docs/ipv6-rootservers.html). If any of the DNS root operators applies for the address space there are /32 reserved for them.
Ok. Perhaps i've previously badly phrased it: "...provided that RIPE applies its policy the same way APNIC did." :-)
- "I" at Stockholm, Sweden; - "K" at London, England.
As for the K (being an operator of this server) we don't have definite plans for ipv6 deployment. Also there are different views on how ipv6 access should be provided to the root zone.
One view is enabling IPv6 (as far as it is possible) on the root servers. The other views are? - only some should be enabled (dual-stacked) - the timeline is unappropriate - ...
Regarding the other 10 dns root servers, 2 of them already have IPv6 assignments from ARIN's microallocation pool ("F" and "H"), which is in fact a different approach. As we speak im getting around 400ms rtt to "H" and about 240 rtt to "F". Anybody (around Europe) is getting significantly better values?
Any comment on this rtt subject? :-) ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt <cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 "Internet is just routes (125953/461), naming (millions) and... people!"
On Tue, 24 June 2003 15:54:37 +0100, Carlos Friacas wrote:
Regarding the other 10 dns root servers, 2 of them already have IPv6 assignments from ARIN's microallocation pool ("F" and "H"), which is in fact a different approach. As we speak im getting around 400ms rtt to "H" and about 240 rtt to "F". Anybody (around Europe) is getting significantly better values?
Any comment on this rtt subject? :-)
I think it's easy. Not everyone experimenting with IPv6 has a tunnel to DREN and native IPv6 in the US is tough. With regards to F what you see in your routing table is transit for their Palo Alto node, as only for that peers are allowed to do transit. They have a node in New York which some networks there peer with but are not allowed to do transit for, so it's only of benefit to these networks directly. Regards, Alexander PS: AS-TISCALI-V6PEERS -- Alexander Koch <koch@tiscali.net> / ako4-ripe IP Engineering, Tiscali International Network Robert-Bosch-Strasse 32, D-63303 Dreieich, Germany Phone +49 6103 916 480, Fax +49 6103 916 464
Hi, On Tue, Jun 24, 2003 at 04:46:01PM +0200, Andrei Robachevsky wrote:
As for the K (being an operator of this server) we don't have definite plans for ipv6 deployment. Also there are different views on how ipv6 access should be provided to the root zone.
Could you explain this a bit more? I'm curious what's going on. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering wrote:
Hi,
On Tue, Jun 24, 2003 at 04:46:01PM +0200, Andrei Robachevsky wrote:
As for the K (being an operator of this server) we don't have definite plans for ipv6 deployment. Also there are different views on how ipv6 access should be provided to the root zone.
Could you explain this a bit more? I'm curious what's going on.
I was referring to the problem with priming, where one can fit only two AAAA records in the priming response provided that not all DNS implementations support EDNS0 at the moment. One proposal I heard of suggests that two selected root servers provide anycast service in ipv6. I thought it was going to be published as an internet draft but cannot find it.
Gert Doering -- NetMaster
Andrei
Andrei, there are 2 issues here, one is how to provide transport and another how to include records in the root zone (this is the one you are referring to but NOT the one this thread started with). There is no reason not to enable IPv6 transport. It is dependant only on the operator of the machine. People will find ways to use the service (the ones who don't already do so with the available servers) if the service is available, so the first step is to enable the service. Joao On Wednesday, Jun 25, 2003, at 09:00 Europe/Amsterdam, Andrei Robachevsky wrote:
Gert Doering wrote:
Hi, On Tue, Jun 24, 2003 at 04:46:01PM +0200, Andrei Robachevsky wrote:
As for the K (being an operator of this server) we don't have definite plans for ipv6 deployment. Also there are different views on how ipv6 access should be provided to the root zone. Could you explain this a bit more? I'm curious what's going on.
I was referring to the problem with priming, where one can fit only two AAAA records in the priming response provided that not all DNS implementations support EDNS0 at the moment. One proposal I heard of suggests that two selected root servers provide anycast service in ipv6. I thought it was going to be published as an internet draft but cannot find it.
Gert Doering -- NetMaster
Andrei
On Tuesday, Jun 24, 2003, at 16:46 Europe/Amsterdam, Andrei Robachevsky wrote:
As for the K (being an operator of this server) we don't have definite plans for ipv6 deployment. Also there are different views on how ipv6 access should be provided to the root zone.
By configuring IPv6 addresses in the interfaces and advertising a prefix to your IPv6 capable peers? It might not be in the "root zone" but that is a different story than providing IPv6 access. Someone said a long time ago: "connectivity is its own reward", so enable the services and the traffic will come to you. Joao
Carlos Friacas <cfriacas@fccn.pt> writes:
Regarding the other 10 dns root servers, 2 of them already have IPv6 assignments from ARIN's microallocation pool ("F" and "H"), which is in fact a different approach. As we speak im getting around 400ms rtt to "H" and about 240 rtt to "F". Anybody (around Europe) is getting significantly better values?
98ms from Munich to F. I'm sure we can find a solution for this together with ISC. We are providing transit for a number of public infrastructure and can also give you F (v4 and v6 actually) where we meet. As for H, unfortunately the operators unfortunately haven't responded to queries about establishing connectivity. This is very disappointing. Robert
Dear Andrius, Andrius Kasparavicius wrote:
hi, why there is no "nameserver" records in inet6num? Also it would be
"nameserver:" attribute can appear in the "domain" object representing delegation. "inetnum" and "inet6num" objects contain optional "rev-srv:" attribute, that is not used in RIPE NCC's reverse delegation process.
useful to have reverse zones on ftp.ripe.net, like in-addr now is. Also,
That can be done, though at some point we'd prefer to see the RIPE Database as a single and authoritative source of this information (apart from DNS itself of course). To facilitate this a "-d" flag was introduced in the database allowing one to walk up and down the reverse domains tree using an IP address as a search key. For instance: whois -dr -Tdomain 2001:778::/32 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html domain: 7.0.1.0.0.2.ip6.arpa [...] One can also use -MmlL modifiers.
maybe could someone explain why dig -x 2001:778:: NS doesn't work? Is it my fault?
If you are the holder of 2001:778::/32 allocation you may request reverse delegation for this space following the procedure http://www.ripe.net/ripencc/mem-services/registration/reverse/ipv6.html
best regards, Andrius
Regards, Andrei Robachevsky CTO, RIPE NCC
participants (13)
-
Alexander Koch -
Andrei Robachevsky -
Andrius Kasparavicius -
Carlos Friacas -
Gert Doering -
Jeroen Massar -
Joao Damas -
Joao Damas -
Joao Luis Silva Damas
-
Joao Luis Silva Damas
-
Kurt Bauer -
Robert Kiessling -
Simon Leinen