IPv6 Day

[GreyGeek]

Found a couple of interesting tools:

nm-tool

:~$ sudo nm-tool
[sudo] password for jerry: 


NetworkManager Tool


State: connected (global)


- Device: eth0 -----------------------------------------------------------------
  Type:              Wired
  Driver:            atl1c
  State:             unavailable
  Default:           no
  HW Address:        38:60:77:78:40:C8


  Capabilities:
    Carrier Detect:  yes


  Wired Properties
    Carrier:         off




- Device: wlan0  [GreyGeek] ----------------------------------------------------
  Type:              802.11 WiFi
  Driver:            rtl8192ce
  State:             connected
  Default:           yes
  HW Address:        74:DE:2B:36:E4:35


  Capabilities:
    Speed:           72 Mb/s


  Wireless Properties
    WEP Encryption:  yes
    WPA Encryption:  yes
    WPA2 Encryption: yes


  Wireless Access Points (* = current AP)
    WIN_f0a6:        Infra, 2C:E4:12:46:F0:A5, Freq 2412 MHz, Rate 54 Mb/s, Strength 80 WPA WPA2
    BettyBoop:       Infra, C0:C1:C0:24:95:3C, Freq 2412 MHz, Rate 54 Mb/s, Strength 80 WPA2
    linksys:         Infra, 00:13:10:89:75:0D, Freq 2437 MHz, Rate 11 Mb/s, Strength 100
    5dfe:            Infra, 20:4E:7F:7A:09:02, Freq 2412 MHz, Rate 54 Mb/s, Strength 100 WPA WPA2
    belkin.fec:      Infra, 08:86:3B:29:8F:EC, Freq 2462 MHz, Rate 54 Mb/s, Strength 69 WPA WPA2
    *GreyGeek:       Infra, 20:AA:4B:3A:85:E3, Freq 2462 MHz, Rate 54 Mb/s, Strength 67 WPA2
    GarberNetgear:   Infra, 2C:B0:5D:81:97:BE, Freq 2422 MHz, Rate 54 Mb/s, Strength 79 WPA2
    WIN_A9E8:        Infra, 4C:17:EB:20:A9:E7, Freq 2412 MHz, Rate 54 Mb/s, Strength 85 WPA WPA2
    The Alois Family:Infra, 00:1E:58:32:BB:35, Freq 2412 MHz, Rate 54 Mb/s, Strength 79 WPA


  IPv4 Settings:
    Address:         192.168.1.100
    Prefix:          24 (255.255.255.0)
    Gateway:         192.168.1.1


    DNS:             207.69.188.186
    DNS:             207.69.188.187
    DNS:             192.168.1.1
:~$

and
routel

:~$ routel
         target            gateway          source    proto    scope    dev tbl
        default        192.168.1.1                   static           wlan0 
   169.254.0.0/ 16                                              link  wlan0 
   192.168.1.0/ 24                   192.168.1.100   kernel     link  wlan0 
      127.0.0.0          broadcast       127.0.0.1   kernel     link     lo local
     127.0.0.0/ 8            local       127.0.0.1   kernel     host     lo local
      127.0.0.1              local       127.0.0.1   kernel     host     lo local
127.255.255.255          broadcast       127.0.0.1   kernel     link     lo local
    192.168.1.0          broadcast   192.168.1.100   kernel     link  wlan0 local
  192.168.1.100              local   192.168.1.100   kernel     host  wlan0 local
  192.168.1.255          broadcast   192.168.1.100   kernel     link  wlan0 local
2001:4978:f:580::/ 64                                   kernel           sixxs 
        fe80::/ 64                                   kernel           sixxs 
        fe80::/ 64                                   kernel           wlan0 
        default    2001:4978:f:580::1                                    sixxs 
        default        unreachable                   kernel              lo unspec
            ::1                 ::                     none              lo local
2001:4978:f:580::2                 ::                     none              lo local
fe80::4878:f:580:2                 ::                     none              lo local
fe80::76de:2bff:fe36:e435                 ::                     none              lo local
        ff00::/ 8                                                     sixxs local
        ff00::/ 8                                                     wlan0 local
        default        unreachable                   kernel              lo unspec
jerry@jerry-Aspire-7739:~$

Don't know what those two "unreachable" defaults are, but I'm assuming that there can be only one default.


and, not a new tool, but some interesting output:
ip r s t all

:~$ ip r s t all
default via 192.168.1.1 dev wlan0  proto static 
169.254.0.0/16 dev wlan0  scope link  metric 1000 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.100  metric 2 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.1.0 dev wlan0  table local  proto kernel  scope link  src 192.168.1.100 
local 192.168.1.100 dev wlan0  table local  proto kernel  scope host  src 192.168.1.100 
broadcast 192.168.1.255 dev wlan0  table local  proto kernel  scope link  src 192.168.1.100 
2001:4978:f:580::/64 dev sixxs  proto kernel  metric 256 
fe80::/64 dev sixxs  proto kernel  metric 256 
fe80::/64 dev wlan0  proto kernel  metric 256 
default via 2001:4978:f:580::1 dev sixxs  metric 1024 
unreachable default dev lo  table unspec  proto kernel  metric -1  error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0 
local 2001:4978:f:580::2 via :: dev lo  table local  proto none  metric 0 
local fe80::4878:f:580:2 via :: dev lo  table local  proto none  metric 0 
local fe80::76de:2bff:fe36:e435 via :: dev lo  table local  proto none  metric 0 
ff00::/8 dev sixxs  table local  metric 256 
ff00::/8 dev wlan0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric -1  error -101 hoplimit 255
jerry@jerry-Aspire-7739:~$

You'll notice that in the "nm-tool" listing are the other "AP"'s local to me, and among them, mine has the lowest signal strength at 67%, and I am only 10' from my wireless router! This is the same problem that my other wireless, the WR1043ND, gave me. I am beginning to suspect that it is a problem with the cable modem from TimeWarner.

[dibl]

Oops... "The SB5101 cable modem is a high-speed ultra-broadband data solution incorporating DOCSIS 2.0 technology."

Precisely so -- thus my need to plan a migration! ;-)

[GreyGeek]

Thanks GG. I have a SB5101 on my end of my TW cable, so I'll wait and see how you fare with them and plan my migration accordingly.

Oops... "The SB5101 cable modem is a high-speed ultra-broadband data solution incorporating DOCSIS 2.0 technology."

[dibl]

Thanks GG. I have a SB5101 on my end of my TW cable, so I'll wait and see how you fare with them and plan my migration accordingly.

[GreyGeek]

Is the TW modem the only limiting factor for TW customers? I had the impression, from where I'm not sure, that the ISPs have other infrastructure that prevents IPv6 connectivity. Have you discussed it with TW?

(Curious TW customer here .....).

Thanks GG!

As I understand it, hardware which needs to inspect packets to determine where they go must use DOCSIS 3.0 in order to work in an IPv6 environment. Equipment which simply passes packets along isn't affected by nor will affect IPv6 packets.

TW has reported that they are "IPv6 ready" and that "1%" of their customer base is on IPv6 already. I suspect that they are rolling out the business class users first, then premium users, etc... But, your cable modem has to use DOCSIS 3.0 or it can't do IPv6. My modem is a Cisco DCP2100R2, which uses DOCSIS 2.0. So, I am going to get it replaced one way or another. If TW doesn't agree to a swap, or wants to "rent" a DOCSIS 3 class router to me, then I will decline the offer, buy a Motorola SB6121 and call them up and give them the serial number and MAC address and tell them to activate it.

[SteveRiley]

Here's my plan:
Yesterday I replaced my old wireless router with one which supports IPv6. Today I am going to get TW to replace their modem with one which supports IPv6. Then I am going to make my wireless work in IPv6 only, and use tnat64 from the repository to connect to IPv4 websites.

Workable?

A NAT64 translator usually won't work properly without a DNS64 to synthesize appropriate AAAA records. totd appears to be the Linux tool that will do this for you. I don't have any personal experience with any of the Linux NAT64/DNS64 stuff yet, though, so I can't offer an opinion on how well these utilities behave.

[dibl]

Today I am going to get TW to replace their modem with one which supports IPv6.

Is the TW modem the only limiting factor for TW customers? I had the impression, from where I'm not sure, that the ISPs have other infrastructure that prevents IPv6 connectivity. Have you discussed it with TW?

(Curious TW customer here .....).

Thanks GG!

[GreyGeek]

Here's my plan:
Yesterday I replaced my old wireless router with one which supports IPv6. Today I am going to get TW to replace their modem with one which supports IPv6. Then I am going to make my wireless work in IPv6 only, and use tnat64 from the repository to connect to IPv4 websites.

Workable?

[SteveRiley]

I notice that there are two Tayga apps in the repository. Time to experiment some more!

6rd is probably a better option for you, and SIIT might also work. But I don't have any hands-on experience with these particular protocols.

[SteveRiley]

did you take a look at my nmap results ........do you think I'm reasonably secure using miredo ?

Teredo, by itself, isn't so bad -- but because it advertises a globally unique IPv6 address to the Internet and also has to sit on a UDP port awaiting incoming traffic, it exposes your computer to potential attack. This is typical for anything that performs NAT traversal. The success of any attack depends on what else is running on your computer and how you've configured your tunnel adapter.

A Symantec paper covers the risks rather well, even though it's six years old. It gets technical -- IPv6 is a complicated protocol; to assume that it's automatically more secure is a very bad assumption. I predict that during these early days of IPv6 we'll see an increase in attacks, mostly because bad guys will get very good at finding misconfigured IPv6 security controls.

My advice: unless you really need Teredo to do something, I'd suggest stopping your experiment soon. There was some effort a couple years ago to beef up Teredo's validation, but the efforts have largely gone nowhere. Trawling through Google will reveal some half-hearted attempts to explain away the weaknesses, but they are just that: explanations. Fundamentally, allowing unauthenticated tunnels through a private network is a bad idea.

[GreyGeek]

Not everything is accessible with NAT64, such as SIP, Skype, MSN, Google talk, and sites with IPv4 literals.

Oops! :eek:

I notice that there are two Tayga apps in the repository. Time to experiment some more!

[SteveRiley]

NAT64/DNS64 is a much simpler method of allowing IPv6 hosts to communicate with IPv4 hosts. It avoids tunneling and doesn't require that your ISP's DNS server return AAAA records. Even if your ISP is completely IPv6-clueless, you can make your internal home network IPv6-only with the purchase of a NAT64/DNS64 gateway.



Interestingly enough, even Microsoft, the inventor of Teredo, is deprecating it in favor of NAT64/DNS64. All that client/server/relay/broker stuff is really brittle and I'm glad to see it going away.

[vinnywright]

Wow, what a thread to catch up on. You guys have been doing some pretty neat investigation, was fun to read.


Teredo is actually kind of a sucky protocol, and it's on the dinosaur path. It has a number of security issues, not least in that it creates tunnels that bypass NAT devices. It's a useful tool for routing around many firewalls, unfortunately. If I were building an enterprise network, I'd block it completely. There are much better ways to accomplish this particular form of IPv6 transition, namely NAT64/DNS64.

Hummm so would this NAT64/DNS64 work with my crusty old router that may/may not be IPv6 capable ?

heck my ISP is not even using IPv6 yet ....or at least "host" dose not return any AAAA records for it.

did you take a look at my nmap results ........do you think I'm reasonably secure using miredo ?

we value your opinion

VINNY

[SteveRiley]

Wow, what a thread to catch up on. You guys have been doing some pretty neat investigation, was fun to read.

I'm sure you've realized now what Teredo is: a tunneling protocol that allows IPv6 capable hosts to communicate on IPv4 networks like the Internet. By installing and configuring miredo, you're creating a virtual tunnel adapter whose address is in the 2001:0::/32 range, the dedicated range for Teredo clients. The other end of your Teredo connection is to a Teredo relay someplace on the Internet. A Teredo server (not the same thing as a relay) takes care of configuring the tunnel when you first connect. A number of public servers and relays exist.

When your computer sends traffic to the IPv6 Teredo adapter, it's actually IPv4 datagrams that then get encapsulated in IPv6. These are forwarded to the Teredo relay, which un-encapsulates the traffic and forwards it to its IPv4 destination.

A Teredo address reveals clues about its construction. After the first 32 bits, the next 32 bits (the ones you guys have been asking about) are the IPv4 address of the Teredo server that configured your tunnel. The next 16 bits are flags, the next 16 bits are an obfuscation of the IPv4 UDP port via which your client is tunneling, and the final 32 bits are an obfuscation of your IPv4 address.

Teredo is actually kind of a sucky protocol, and it's on the dinosaur path. It has a number of security issues, not least in that it creates tunnels that bypass NAT devices. It's a useful tool for routing around many firewalls, unfortunately. If I were building an enterprise network, I'd block it completely. There are much better ways to accomplish this particular form of IPv6 transition, namely NAT64/DNS64.

[vinnywright]

Okay, so I can connect via IPv6 or IPv4, but my client (Chromium ?) is using IPv4 over IPv6. Is this something I can change?

edit your /etc/gai.config as I described earlier .........

VINNY

EDDIT in post #22 .....