XPost: comp.os.linux.networking   
   From: ivan@gray.siamics.net   
      
   >>>>> Noob   writes:   
      
   […]   
      
    > Obviously, the STB is not able to talk directly to ipv6.google.com   
    > since it does not support IPv6.   
      
    > I see several work-arounds.  The server could be dual stack, and   
    > provide ALSO an IPv4 address, but 1) IPv4 address space is running   
    > out and 2) the STB might be confused by the IPv6 addresses in the DNS   
    > reply, even if it should just ignore them.   
      
   	Let's check it out:   
      
   $ dig ipv6.google.com A   
      
    <<>> DiG 9.7.2-P3 <<>> a ipv6.google.com   
   ; global options: +cmd   
   ; Got answer:   
   ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51576   
   ; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0   
      
   ; QUESTION SECTION:   
   ipv6.google.com.		IN	A   
      
   ; ANSWER SECTION:   
   ipv6.google.com.	0	IN	CNAME	ipv6.l.google.com.   
      
   ; AUTHORITY SECTION:   
   l.google.com.		60	IN	SOA	ns2.google.com. dns-admin.google.com. 1457624 900 900   
   1800 60   
      
   ; Query time: 252 msec   
   ; SERVER: ::1#53(::1)   
   ; WHEN: Thu Jul 28 21:01:10 2011   
   ; MSG SIZE  rcvd: 104   
      
   $   
      
   	As could be seen from the above, no AAAA (IPv6 address) resource   
   	records were returned by the server.  So, there's nothing to   
   	confuse the device in question.   
      
   	(Of course, it's unlikely that an IPv4-only device will ever   
   	request AAAA records from the DNS server.  Neither should it   
   	request ANY.)   
      
   […]   
      
   --   
   FSF associate member #7257   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)