On Tue, 16 Jun 2009, Chris Morrow wrote:

On Tue, 16 Jun 2009, Michael Sinatra wrote:

...

If I have decoded the 6to4 address properly, the RAs are being announced by the host with IPv4 address 75.196.207.17, which is a Verizon Wireless

code to decode addr pls.

i ask because: morrowc@tweezer:~$ ifconfig wlan0 | grep 2002 inet6 addr: 2002:4bc4:cf11:b:58bd:5bee:d59b:c8c6/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:21d:e0ff:fe90:1acb/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:74b9:a96e:55af:6abd/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:dd31:7550:87c2:747b/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:91d2:ac70:e21c:157f/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:a425:3a98:1398:2dbd/64 Scope:Global it'd be nice to hammer down on the others there :) (other 6 from what I can tell)

Chris Morrow <morrowc@ops-netman.net> writes:

code to decode addr pls.

i ask because:

morrowc@tweezer:~$ ifconfig wlan0 | grep 2002 inet6 addr: 2002:4bc4:cf11:b:58bd:5bee:d59b:c8c6/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:21d:e0ff:fe90:1acb/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:74b9:a96e:55af:6abd/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:dd31:7550:87c2:747b/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:91d2:ac70:e21c:157f/64 Scope:Global inet6 addr: 2002:4bc4:cf11:b:a425:3a98:1398:2dbd/64 Scope:Global

it'd be nice to hammer down on the others there :) (other 6 from what I can tell)

the way 6to4 works is basically it's a way to make yourself a /48 out of an ipv4 address. 2002:: is the first 16 bits; the next 32 bits is your ip address, thus 192.148.252.11 would be c094ffc0b in hex and your /48 prefix is 2002:c094:fc0b::/48. the rest of the address would be a random subnet chosen and an eui64 style host address most likely. -r

The rogue dhcp server has to reply faster than the actual one. We don't actually have an protection against rogue dhcp servers currently in my understanding. so if you don't see any it's because there aren't any. joel On Wed, Jun 17, 2009 at 7:08 AM, Michael Sinatra<michael@rancid.berkeley.edu> wrote:

On 6/16/09 3:25 PM, Tom Pusateri wrote:

...

Shouldn't we see the same problem with rogue DHCP servers in v4?

That's what has always confused me.  Part of the reason we may not is that the rogue comes on-line at a time when nobody is doing DHCPDISCOVER and then goes off-line.  OTOH, if the rogue sends out just one RA, other machines will configure the address and might even add a candidate route immediately, regardless of whether they already have a v6 address.

However, I have been in other situations where I see RAs in IPv6, but I don't have rogue DHCP issues in v4 on a particular net.  (At the same time, we do see a bunch of rogue DHCP servers on our wireless nets at Berkeley.)

michael

_______________________________________________ Attendee mailing list Attendee@nanog.org http://mailman.nanog.org/mailman/listinfo/attendee

In a message written on Tue, Jun 16, 2009 at 06:25:15PM -0400, Tom Pusateri wrote:

Shouldn't we see the same problem with rogue DHCP servers in v4?

There are two fundamental differences. I've had long discussions with some IETF folk about them. * A rogue DHCP server does not break a working connection immediately. A common problem is someone boots their laptop with the 3G card still in it set up for sharing from where they were the day before, or similar. They often find their own connectivity broken, or slow in a matter of minutes, pull it out, and reconfigure. Let's even assume they were using a DHCPv4 server on it. In IPv4+DHCP if you were already up on the LAN, the fact that a new DHCP server came up is uninteresting until you need to renew. Since most leases are 7-30 days, and the broken laptop is in the broken config for a matter of minutes it's quite unlikely anyone will be broken, and if they are it is one or two folks. In IPv6+RA's, the second that laptop boots it sends RA's, and depending on a number of things that may break everyone on the lan in a matter of milliseconds. Worse, when the person realizes and yanks out the 3G card the software does not withdraw the route, so the folks that were broken in millisecond are now waiting for a two hour timeout during which the packets are blackholed. * IPv6 has the assumption you want multiple addresses. Raise your hand if you've accidently plugged an ethernet cable into the wrong port on a switch before. *looks* Yeah, I think that's everyone. In IPv4+DHCP, if I take two, working subnets and accidently connect them (bridge) generally nothing happens. DHCP renewals are even unaffected. New clients may select the wrong network, but that's only an issue in highly dynamic networks. Unplugging the cable instantly returns everything to a working state. In IPv6+RA's, if I take two working subnets and accidently bridge them in a matter of milliseconds the hosts detect this fact and every host numbers itself on both networks. Worse, if I then unplug the network, because I realized 20 seconds later it was the wrong port on the switch, /I remove the ability for RA withdraws/ and every host in both networks is back to a two hour expiration. The end result of all this is that from a theoretical level these look like similar issues. DHCP is unauthenticated. RA's are unauthenticated. People run rogue versions of both. However from an operational level the RA model causes more outages, causes outages faster, and makes them last longer. In that sense, I've taken to describing IPv6+RA's as less /robust/ than IPv4+DHCP in average deployments. What is the solution? Well, there are, in my mind, three basic tracts and I think it's important we go down all of them: * "Secure RA". There is an effort to secure, using crypto, the RA's in some useful way. I have some concerns, but that is good work and should be continued. * Make it possible to run DHCPv6 in the same way as DHCPv4, that is hand out a default router. DHCPv6 relies on RA's to work. In essence you can't turn off RA's and have a working network. There are plenty of folks experienced with IPv4+DHCPv4, and for a lot of deployments it is "robust enough". The fact that this option has been removed is a major step backwards in my mind. DHCPv6 needs to be updated to allow operating an "RA-less" network, which probably also means finishing VRRPv6. I know IPv6 folks hate operators who say "make it work like IPv4", but in this case it is an option that should be on the table. * Enhance LAN equipment to track RA's. Those who need a more secure environment today prevent DHCP servers on "user" ports via DHCP snooping. They make sure the host can only source IP from the address the DHCP server told them. There's a set of 3-5 features, in the layer 2 switches to "lock down" dynamic addressing. The same is needed for IPv6. RA snooping, preventing user ports from advertising RA's, etc. Anyone who's been to a NANOG or IETF has seen the issue with rogue RA's. Indeed, on a day to day basis I would say this is the only thing left where I think there is a significant impediment to IPv6 deployment, and where IPv6 is significantly worse than IPv4 for all of the typical cases. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/