Print

[BobRobertson]

I looked at the product manual for the D-Link DIR-825, and the IPv6 setup screens match with the IPv6 configuration screen shots for the -615 that I found through a Google search.

Then I noticed the difference in the prices between the two.

As nefarious as this may sound, could IPv6 support in the -615 have been dropped in order to get people to spend an additional $100 for the -825?

[snarked]

The 825 also does the 5GHz band, while the 615 is a 2.4GHz band only device.  There's also the "shared storage" USB port ("shared" - in that it may be accessed from only one source at a time) for thumbdrives.

[jimb]

Sounds like the WRT-610N that I bought.  I'm not using any of the routing or "media" functionality it has.  Using it as a simple access point.  I bought it 'cause it's the only Linksys which has the simultaneous dual bands + GB enet ports on its switch.  I probably should have shopped around a bit more.

5ghz is nice.  Like I have the air to myself.   

[BobRobertson]

Well, after deciding that I like the GUI interface of dd-wrt, I also gave up on my Linksys 54GL and bought a DIR-615.

Turns out the dd-wrt that does v6 only comes with the 2.6 kernel, and that requires seriously messing with the 54GL, far more than I'm comfortable with.

I made sure the DIR-615 was the hardware C1, much to the interest of the drone at Office Depot but at least it was printed on the OUTSIDE of the box, and set it up as per other people's comments here. "Stateful" rather than "Stateless" was the final straw that made everything work.

The most surprising thing was using one /64 for both the WAN and LAN, doing what I would call "bridging" rather than routing. It's fine by me, and a much better use of address space than having every circuit be its own network block.

Anyway, it works and I'm glad. Now to sell a perfectly good WRT-54GL with dd-wrt on it, and a Belkin "Wireless G" that I was using before it.

[broquea]

It shouldn't be using the same /64. Looking at my screenshots of the webUI, I can clearly put in the routed /64 for the LAN

[jimb]

@bob:  Are you saying you're bridging the LAN and the WAN, or the LAN and the WLAN?

First is kind of silly since you automatically get a routed /64 with your tunnel, but I can see how it might work unless HE has ACLs blocking anything other that host 1 and 2.

Second is just fine.  

EDIT: OK I read another post where you seem to confirm that you actually bridged the HE tunnel /64 to your LAN.  There really is no point in doing that since you have a perfectly good /64 routed to you already.  Doing something like that is what I call an "unnatural act" (actually borrowed that term from a old CTO friend of mine) and will only wind up getting you into trouble in the future. 

[BobRobertson]

Oh, I agree it's an un-natural act, but I only have one /64 defined, not two.

Or rather, if I have two, where do I find the second one? I didn't ask for a /48, hardly needing a /64. A /96 would have been just fine. Being profligate with addresses from the start seems to be a violation of what we learned from IPv4.

Personally, I'd rather see the link defined from a standard pool of /126's, the same way an ISP I worked for used a /30 for each link, since "all 0" and "all 1" are reserved for broadcast. That was before un-numbered interfaces, a development that was long overdue in my humble opinion. I also tried the "un-numbered" technique on this DIR-615 at first, but that didn't work. Numbering the LAN interface with ::3 was just a shot in the dark, and it did work.

The Tunnelbroker.net/main shows me just the one /64 and no deligated /48.

Here's the DIR-615 IPv6 config page, so you can see what I did:



I can smudge the addresses if anyone thinks it's wise, I wanted the addressing to be unequivocal. Please let me know.

I call that a bridge. Which is fine, since it works.

[mtindle]

Being profligate with addresses from the start seems to be a violation of what we learned from IPv4.

Many years ago when I was first setting up IPv6 on our network, I had the same mental hurdle to get over.  Initially tunnel endpoints were created as /127s but it ended up causing more problems than it was worth. A lot of devices will not work correctly without having a /64 for EUI-64. 

The scale of available v6 addresses is actually difficult to grasp.  There is no reason to be stingy with them.  So far this is the best example I've run across that describes just how much address space we are dealing with in v6 land as opposed to v4.

To make this diagram to scale, imagine the IPv4 address space is the 1.6-inch square above. In that case, the IPv6 address space would be represented by a square the size of the solar system.

http://www.tcpipguide.com/free/t_IPv6AddressSizeandAddressSpace-2.htm

[jimb]

LOL.  OK.  It isn't bridged.  It's routed.  You are using your routed /64 on the LAN.  You made it sound like you were using your /64 tunnel IPv6 and bridging it to the LAN.  Bridging is when you connect two physical segments using layer-2 (link layer) networking.  In other words, in this case, your 6in4 interface and LAN interface would appear to be the same LAN.

Since you're using separate /64s (2001:470:1f06:72a::/64, 2001:470:1f07:72a::/64), you are actually routing, not bridging.  

Or rather, if I have two, where do I find the second one? I didn't ask for a /48, hardly needing a /64. A /96 would have been just fine. Being profligate with addresses from the start seems to be a violation of what we learned from IPv4.

Personally, I'd rather see the link defined from a standard pool of /126's, the same way an ISP I worked for used a /30 for each link, since "all 0" and "all 1" are reserved for broadcast. That was before un-numbered interfaces, a development that was long overdue in my humble opinion. I also tried the "un-numbered" technique on this DIR-615 at first, but that didn't work. Numbering the LAN interface with ::3 was just a shot in the dark, and it did work.

You didn't have to use ::3, ::1 would have worked fine, since it's a different network address.

I used to worry about IPv6 address conservation too, but a saying goes like this:  "When you live in a rain forest, you don't worry about water."  Coming from the IPv4 "desert", where extreme conservation strategies are the norm and desirable, it's hard to transition your thinking to the IPv6 mode, where address space is so abundant we don't have to worry about running out of space.  

Allow me to quote myself:

Addressing plans will depend largely on the ISP's own policies.  But the IAB outlines recommendations in RFC3177.  Basically it says that end users should get either a /64 if they have a single LAN, or a /48 if they have multiple LANs.  Businesses will also get /48s (one or multiple).  ISPs get /32s.  Also, just the currently assigned global unicast range, 2000::/3 (2000:: - 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) contains ~537 million /32s (2^29 /32s).  So running out of /32s for ISPs won't happen any time soon.  And every /32 has 64Ki /48s, which in turn has 64Ki /64s, each of which have 2^64 - 1 interface addresses.

Realize this isn't the entire IPv6 space, just the current 2000::/3 which is what that ICANN has currently assigned for global unicast IPv6.  There are a bunch of other like sized ranges reserved which can be rolled out later, perhaps with different address plan standards.

And here's a snippet from RFC3177, a guideline put out by the IAB on IPv6 address assignment:


 In particular, we recommend:

      -  Home network subscribers, connecting through on-demand or
         always-on connections should receive a /48.
      -  Small and large enterprises should receive a /48.
      -  Very large subscribers could receive a /47 or slightly shorter
         prefix, or multiple /48's.
      -  Mobile networks, such as vehicles or mobile phones with an
         additional network interface (such as bluetooth or 802.11b)
         should receive a static /64 prefix to allow the connection of
         multiple devices through one subnet.
      -  A single PC, with no additional need to subnet, dialing-up from
         a hotel room may receive its /128 IPv6 address for a PPP style
         connection as part of a /64 prefix.

   Note that there seems to be little benefit in not giving a /48 if
   future growth is anticipated.  In the following, we give the
   arguments for a uniform use of /48 and then demonstrate that it is
   entirely compatible with responsible stewardship of the total IPv6
   address space.


So don't worry about waste.  I've been admonished about this myself and told it was "IPv4 thinking."

Also, you may want to take a look at:  RFC4291 (info about IPv6 addresses), RFC3177 (IPv6 address plan recommendations), and RFC3627 (recommendation against using /127s).

[BobRobertson]

1f06, 1f07

This is one of those "aww poop" moments. Seriously, I looked at that and looked at that and just didn't see it. I sat there dumbfounded as to why the LAN address was the same as the link, seriously. As is obvious from my earlier, which I will leave as an object lesson in silliness.

I bow to the gods of Cut and Paste, which is the only reason it worked at all.

You didn't have to use ::3, ::1 would have worked fine, since it's a different network address.

Yeah, like I said, right there with ya. Lots of excuses, only one reason: I just didn't see it.

In a firefight, I'd be dead.

Coming from the IPv4 "desert", where extreme conservation strategies are the norm and desirable, it's hard to transition your thinking to the IPv6 mode, where address space is so abundant we don't have to worry about running out of space.

 

While I agree as things are, things will not always be this way. Interstate highways have traffic jams, OC3 circuits get filled, 16MB Token Ring seemed fast. It happens, it will happen.

Ok, a /126 is completely absurd. 

I am reminded of John D. Rockefeller, who lived in a single rented room with little more than a nightstand and a bed, to the end of his days. But then, not spending what he didn't need to was how he got rich in the first place.

Realize this isn't the entire IPv6 space, just the current 2000::/3 which is what that ICANN has currently assigned for global unicast IPv6.  There are a bunch of other like sized ranges reserved which can be rolled out later, perhaps with different address plan standards.

Or different planets.

So don't worry about waste.  I've been admonished about this myself and told it was "IPv4 thinking."

Shows where I cut my teeth, certainly.

Thanks for the pointers, and for not laughing too hard.

[jimb]

1f06, 1f07

This is one of those "aww poop" moments. Seriously, I looked at that and looked at that and just didn't see it. I sat there dumbfounded as to why the LAN address was the same as the link, seriously. As is obvious from my earlier, which I will leave as an object lesson in silliness.

I bow to the gods of Cut and Paste, which is the only reason it worked at all.

You didn't have to use ::3, ::1 would have worked fine, since it's a different network address.

Yeah, like I said, right there with ya. Lots of excuses, only one reason: I just didn't see it.

In a firefight, I'd be dead.

This is not even close to the first time this has happened.  A lot of people got caught out by this, including myself!  When I first set up my tunnel, I "missed" the routed /64, and in my haste figured that they only gave you the /64 for the tunnel, and requested a /48 for my LAN.  Only later did I realize that the two addresses were not the same and go "doh!" like Homer Simpson.  

The main reason for the confusion is that that tunnel and routed /64 pair are only different by a single character in the 3rd quad, the tunnel being even and the routed being odd.  This makes it hard to spot.  I even annoyed (likely) kcochran into doing something to make the differences more apparent on the web page, and he bolded the 3rd quad.  But obviously it still catches people out.  Maybe it's because from IPv4 we're used to looking at the trailing bytes of the address for subnets?  Although that's not true of a /24, which matches up with a IPv6 /48 well as far as "positional aspects" (both change in the 3rd section of the address).  Who knows.  I should ask my human factors engineering psychology friend perhaps.  

The HE address plan for the TB stuff seems to be to reserve one /47 per tunnel server, giving two consecutive /48s for the tunnel and routed /64 networks assigned to each user.  It could actually be shorter prefixes but I haven't seen enough address/router associations to guess this.  

But my guess is one /47 per tunnel server, allowing them to provision 65,536 tunnels per server (which is probably more than one can handle).  The fourth quad is always the same per tunnel for the tunnel/routed /64, and is treated as the "local tunnel ID" (if you convert the hex to decimal, you'll see it matches the "local tunnel ID" on the info page for your tunnel).  This is why the addresses look like they do.

With this scheme, they can advertise one /47 per tunnel server into their routing protocols, and it also makes the route table on each server easy to interpret.  They can easily tell the tunnel /64 from the routed /64 based on even/odd, and identify each user's networks based on the 4th quad (local tunnel ID).  (correct me if I'm wrong about any of this HE)

Anyway, this is why the addresses presented to the user for their two networks are only different by one character!

Coming from the IPv4 "desert", where extreme conservation strategies are the norm and desirable, it's hard to transition your thinking to the IPv6 mode, where address space is so abundant we don't have to worry about running out of space.

 

While I agree as things are, things will not always be this way. Interstate highways have traffic jams, OC3 circuits get filled, 16MB Token Ring seemed fast. It happens, it will happen.

Ok, a /126 is completely absurd.  

I am reminded of John D. Rockefeller, who lived in a single rented room with little more than a nightstand and a bed, to the end of his days. But then, not spending what he didn't need to was how he got rich in the first place.

True, nothing is for forever, but by the time we need more, we'll probably be on IPv10 which will address special requirements for quantum entanglement ansibles and FTL communication or something.  

Realize this isn't the entire IPv6 space, just the current 2000::/3 which is what that ICANN has currently assigned for global unicast IPv6.  There are a bunch of other like sized ranges reserved which can be rolled out later, perhaps with different address plan standards.

Or different planets.

So don't worry about waste.  I've been admonished about this myself and told it was "IPv4 thinking."

Shows where I cut my teeth, certainly.

Thanks for the pointers, and for not laughing too hard.

Heh yeh.  But at the rate we're going with space exploration (compare the movie "2010" with "reality 2010" :lol: ) we'll probably be using "IPv10" or something (as I joked earlier) by the time we're on different planets.  

I certainly wasn't laughing, since I (and a bunch of others) were also caught out by this, and I've been a sys/net admin since 1988.  

[BobRobertson]

Maybe it's because from IPv4 we're used to looking at the trailing bytes of the address for subnets?

I would say that is exactly what is happening. "We" learn short-cuts over time, and looking at the least significant digits for the difference in network numbers "always" saved brain cycles before. New habits.

I know of no reason why the 3rd quad "should" be changed, since the same numbering schemes could be used and change by even/odd the 4th quad to accomplish a consecutive allocation of /64s for link and premise. It would fit the pyramid of number allocation more clearly, in my mind, but it's not my mind that designed the HE scheme.

I should ask my human factors engineering psychology friend perhaps.  

Oh No! Not more academics to "explain" why engineers do what they do to make things work.

I have an unofficial minor in economics, it is so frustrating watching those well paid stuffed shirt "economists" pontificate and pronounce on subjects about which it is obvious they have no clue.

With all the grand lecturing on the present economic problems going on endlessly, watching CNN or FNC has become so painful I locked those channels out of my cable selection.

Anyway, this is why the addresses presented to the user for their two networks are only different by one character!

I couldn't agree more that having the two /64 allocations for a single customer different by only one digit is a GoodThing (tm, reg us pat off).

And there is no doubt the person who decided which digit that would be even/odd makes far more than I do right now. I think I have perfectly good reasons for how I would have done it, I'm sure they do too.  

I certainly wasn't laughing, since I (and a bunch of others) were also caught out by this, and I've been a sys/net admin since 1988.  

Hey! I was clearing out some boxes over the weekend, and found the job offer letter for my first Network Engineer job, July 1988! That was IBM mainframe SNA, which makes any version of IP look like a heaven of simplicity. Oh, and DECnet, which actually is a heaven of simplicity, and as obsolete as the 16MB TokenRing SNA cluster controllers we spent huge quantities of money installing in 1992.

Once in a while I indulge in a "if only I knew then what I know now" fantasy. Now I get to do it about events that happened only last week! Hahaha!

[bassin]

Guys,

I'm new to ipv6, and I'm triing to set up my first home tunnel, first I updated my dir-615 firmware to version 3.11NA, then I followed all the posts I finded in the forrum but without sucess my configuration is this one:

Server IPv4 address:     216.66.22.2
Server IPv6 address:    2001:470:7:5c6::1/64
Client IPv4 address:    189.xxx.xxx.21
Client IPv6 address:    2001:470:7:5c6::2/64

inside dlink ipv6 setup I did the configuration in the picture attached, I'm using windows seven with an wireless adapter, in the details page I can see the ipv6 ip and the gateway that is the same as the Server IPv6 address, the dns I had to setup it manualy and used the one provided by tunnelbroker. when I trie to access the internet windows report that there is no connection and when I ping some ipv6 adress inside the router I can do it.

Any advice? I'm almost giving up...

[broquea]

Your D-Link is behind something that assigns it 192.168.0.1 as it's Local IPv4 Address?

If not, you should be putting the IPv4 address you get from the provider for your v4 side of the tunnel.

If so, then it sounds like you are double-natted, and need the first NAT to make sure Protocol 41 is being passed through.

[bassin]

Broquea, you are right, my dir-615 ip address is provided by my adsl modem, but that ip is 10.1.1.2 so I think I understand where the wrong configuration is, I must use the ip that the modem assigns to the router not the local network ipv4 address. I will try it and check the Nat of the modem.

I will post the results thanks for the help