• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Quesiton Regarding Ping and Dig

Started by UltraZero, July 11, 2011, 03:58:20 PM

Previous topic - Next topic

UltraZero

Hi all.  this is just for my information only but, I am sure many people have come across this little item.

I've been noticing when i ping6 and try to obtain a response, there are several system that reply with
the ipv6 address that I am trying to ping.  No IPv6 numbers are showing up.

I was wondering....

Is there a way around this??

Mostly, how is it done?? and does it work on Ipv4 as well??  I'm sure it's something simple...   ;D ;D

in reference to dig, i have used the dig command on a daily basis.  today, i used the dig -x as usual and the data was not accepted
by the daily processes on he.net.
I did the same thing over and over with a different ipv6 address and the response was the same thing.   Then I watched the video posted
on he.net and used the example in the video and it worked. 

Can someone possibly tell me a reason why??  Have I just completely gone bonkers??  I have been doing this for a few weeks now and had no problem before.  Just today..


thanks much.  

cholzhauer


UltraZero

Ask, and ye shall receive...  (just don't ask for a kings ransom)  LOL.

ping6 ipv6.wisc.edu
PING ipv6.wisc.edu(www.ipv6.wisc.edu) 56 data bytes
64 bytes from www.ipv6.wisc.edu: icmp_seq=1 ttl=52 time=107 ms
64 bytes from www.ipv6.wisc.edu: icmp_seq=2 ttl=52 time=106 ms
64 bytes from www.ipv6.wisc.edu: icmp_seq=3 ttl=52 time=107 ms
64 bytes from www.ipv6.wisc.edu: icmp_seq=4 ttl=52 time=107 ms
64 bytes from www.ipv6.wisc.edu: icmp_seq=5 ttl=52 time=107 ms
^C
--- ipv6.wisc.edu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 106.369/107.301/107.949/0.570 ms

cconn


UltraZero

Hmm..

Well.   thanks for this one.  the -n option gives me the IPv6 address alright.  Can  you tell me what
initially makes the system give a non-IPv6 address??

Thanks

cconn

because ping is by default resolving the PTR for the FQDN you are supplying.  :D

from the man page;

      -n     Numeric  output only.  No attempt will be made to lookup symbolic names
              for host addresses.

UltraZero

I understand, but, why is it that some ping responses are not in IP/IPv6 numerical format??  This is kinda something new to me.  I always
in the past saw numerical responses and not fqdn as a response.

Thanks for th -n option (didn't see this in the --help under Linux. )

Is this something of an IP/IPv6 mask??  I did some digging and noticed this is a router option to mask the routers IP address.

jrocha

Quote from: UltraZero on July 13, 2011, 04:35:45 PM
I understand, but, why is it that some ping responses are not in IP/IPv6 numerical format??  This is kinda something new to me.  I always
in the past saw numerical responses and not fqdn as a response.

Thanks for th -n option (didn't see this in the --help under Linux. )

Is this something of an IP/IPv6 mask??  I did some digging and noticed this is a router option to mask the routers IP address.

No, ping is just doing a reverse DNS lookup on the IP address you are pinging. Using ping -n will cause ping not to do those lookups.

UltraZero

Hmm. Now you threw me for a loop.

When I  use the -n option, my system seems to force a lookup for the IPv6 address.  Without it,
I get either option of the name or the address.  I think the -n forces the lookup..

OS.  Linux Ubunt 11.04.  Thanks

UltraZero

In reference to dig, it seems to be either hit or miss.  Some sites reply with a reverse ipv6.ipa and some don't.

johnpoz

#10
There is nothing that forces a PTR record to be created..  Do you have a PTR record for every single one of your /64 IPv6 network that HE is routing to you? ;)

I manage a /16 ipv4 network with control over the in-addr.arpa zone for this network and I can tell you for sure that not all IP's on that netblock that are being used have PTRs

So yeah has been and always will be hit or miss when trying to lookup a in-addr.arpa record, some companies/isp backfill these with say the IP address in host name form.  But we move to IPv6 I can tell you for sure with that sort of address space what 18 quadtrillion IPs in a /64 your not going to see PTRs for every single IP that might be in use.

BTW, this statement not right
"because ping is by default resolving the PTR for the FQDN you are supplying"

To ping a FQDN, say www.domain.tld you have to query for the A record, or AAAA - can not ping it if you don't have the IP.

In your example you gave a FQDN to ping, so why would it report IP vs the name you pinged..  If you want just the IP for that FQDN your pinging then use the -n option as already stated.

cconn

#11
Quote from: johnpoz on July 15, 2011, 08:37:39 AM

BTW, this statement not right
"because ping is by default resolving the PTR for the FQDN you are supplying"

To ping a FQDN, say www.domain.tld you have to query for the A record, or AAAA - can not ping it if you don't have the IP.

In your example you gave a FQDN to ping, so why would it report IP vs the name you pinged..  If you want just the IP for that FQDN your pinging then use the -n option as already stated.

Incomplete maybe, the ping will resolve the A and/or AAAA record for the name supplied as an argument, but it will then resolve the PTR for the IP address it gets and output that in the ping results.


example:

ping6 cconn.info
PING cconn.info(ipv6.hautevitesse.net) 56 data bytes
64 bytes from ipv6.hautevitesse.net: icmp_seq=0 ttl=62 time=4.01 ms
64 bytes from ipv6.hautevitesse.net: icmp_seq=1 ttl=62 time=3.27 ms
64 bytes from ipv6.hautevitesse.net: icmp_seq=2 ttl=62 time=3.72 ms

--- cconn.info ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 3.275/3.672/4.015/0.304 ms, pipe 2

cconn.info is the FQDN I supply, the IP resolves to 2605:2a00:ffff:fffe::10 but the PTR to 2605:2a00:ffff:fffe::10 is ipv6.hautevitesse.net.  So ipv6.hautevitesse.net is what is shown in the ping results....

UltraZero

bbbbbbbbbbbbbbbbbbbbbbbbbbb

:o

Overload.....   :o


buffer full........   :o

clear..................... ;D

o.k. so.. Basically what I gathered is if the recepient of the ping has a PTR pointing to the FQND, then
that is what I will get..  Correct??  Maybe???

And if I want the IP/IPv6 address when this happens, I need to specify the -n option to force
the response with the IP/IPv6 address.

johnpoz

"Incomplete maybe, the ping will resolve the A and/or AAAA record for the name supplied as an argument, but it will then resolve the PTR for the IP address it gets and output that in the ping results."

I stand corrected, you are correct a PTR is queried for on ping in linux after the A or AAAA query, windows does not do this.  I just verified, on my windows box with tcpdump.

So yes on linux if there is a PTR that resolves for that IP, without the -n the ping will return the FQDN of the PTR record for that IP.

In windows if want it to do a PTR you have to use -a and then the IP address, then it does a PTR query.

UltraZero

Excellent. I have been seeing many sites privide the FQDN so I needed to use the -n option.

For the most part, all is well, except of course trying to generate 100 days worth of sites to get info from.

No problem though.  All is working fine. 

Now if I could only find someone who know the CISCO Pix and IPv6?????????  LOL.

Thanks