Print

[dawkco]

Success!  Installing RRAS fixed it.  I just enabled LAN Routing (only) during the Setup Wizard's "Custom Setup" option, then started the service and the Routed/64 started working.  I didn't even have to add any routes or anything else.  That was a relief because the RRAS interface list and routing table didn't show the tunnel interface anywhere and wouldn't allow it to be added to the list--it's hidden and inaccessible in RRAS admin!   |

Please ping me and confirm--thanks:

2001:470:1f05:a85::6

Now I can start configuring the other servers...

[jimb]

Do me a favor--see if you can successfully ping the following address:

2001:470:1f05:a85::6

Thanks.

I can.  So that at least means HE has the route for your /64 pointed through your tunnel.  It may also mean that WS2008 is routing packets, but I'm not sure since that NIC is still "inside" your machine. It all depends on the proto stack framework of windows, etc.

I can also ping your tunnel side interface, BTW.

[dawkco]

I can.  So that at least means HE has the route for your /64 pointed through your tunnel.  It may also mean that WS2008 is routing packets, but I'm not sure since that NIC is still "inside" your machine. It all depends on the proto stack framework of windows, etc.

I can also ping your tunnel side interface, BTW.

Thank you.

The WS2008 machine is definitely routing the packets, and now the Win 2000 Server machine is also as I just finished setting that one up (including RRAS).  I also had to set up a v6v4 tunnel between the WS2008 and Win2000 Server machines (my network is IPv4!  ) and now I'm able to ping through with IPv6.

You should be able to ping my Win 2000 Server now, if you would please:

2001:470:1f05:a85::7

Now, though, there's a new wrinkle in this routing scenario.  When I go to the following web site and use their IPv4/IPv6 connection Checker, they detect my IPv4 NIC address correctly, but the IPv6 address detected is my tunnel endpoint [2001:470:1f04:a85::2] instead of my NIC address [2001:470:1f05:a85::6]:

http://www.ipv6forum.com/

I'm wondering if I should enable some more things on the tunnel.  For example, forwarding is already enabled, but maybe I should also set advertise=enabled nud=enabled routerdiscovery=enabled.  Or, is this due to something else...?  It seems to me that if I get this configured correctly, the NIC address should be the detected source address of the connection.

What do you think?

[cholzhauer]

RouterDiscovery is used for getting an IP address via Router Advertisement.

Unless you're doling out IP addresses via DHCP, this should be on.

[dawkco]

RouterDiscovery is used for getting an IP address via Router Advertisement.

Unless you're doling out IP addresses via DHCP, this should be on.

Well, I'm not using DHCP, but the NIC public/global addresses are manually configured and static.  However, I suppose RouterDiscovery should be enabled for the auto-configured link-local and site-local addresses, correct?

BTW, can you please ping 2001:470:1f05:a85::7 from your location?  Let me know if successful.  Thanks.

[cholzhauer]

  BTW, can you please ping 2001:470:1f05:a85::7 from your location? 

Was able to this morning.

However, I suppose RouterDiscovery should be enabled for the auto-configured link-local and site-local addresses, correct?

AFAIK this will happen regardless if the RouterDiscovery flag is set to true or false.

[jimb]

Why did you have to set up a tunnel from the W2000 machine?

Are they on completely different LANs?  My impression was that the WS2008 box and the other machines were on the same LAN and you were using the routed /64 on that LAN.  In that case they should have all been able to speak to each other directly over ethernet using IPv6.

If they're separated by an IPv4 only router, then you'd either need to tunnel, or use something like ISATAP to route IPv6 over an IPv4 LAN infrastructure (ISATAP basically works by using IPv4 as a link layer protocol for IPv6).  You'd also need to request a routed /48 from HE, since the routed /64 is only good for one LAN and you'd need more subnets.

[dawkco]

  BTW, can you please ping 2001:470:1f05:a85::7 from your location? 

Was able to this morning.

However, I suppose RouterDiscovery should be enabled for the auto-configured link-local and site-local addresses, correct?

AFAIK this will happen regardless if the RouterDiscovery flag is set to true or false.

OK.  Thank you.

[dawkco]

Why did you have to set up a tunnel from the W2000 machine?

Are they on completely different LANs?  My impression was that the WS2008 box and the other machines were on the same LAN and you were using the routed /64 on that LAN.  In that case they should have all been able to speak to each other directly over ethernet using IPv6.

If they're separated by an IPv4 only router, then you'd either need to tunnel, or use something like ISATAP to route IPv6 over an IPv4 LAN infrastructure (ISATAP basically works by using IPv4 as a link layer protocol for IPv6).  You'd also need to request a routed /48 from HE, since the routed /64 is only good for one LAN and you'd need more subnets.

I guess my ignorance is showing--I thought that my LAN was not IPv6 capable.  The 5 machines are connected together via a D-Link Gbit Switch.  If Ethernet is IPv6 compatible, then I guess the D-Link Gbit Switch should be too, so I can just remove the tunnel between the WS2008 and Win2000 Server machines.  That would be good--less bottleneck.  I'll try it.  Thanks for the heads up.

Aside, v6v4 tunnelling is pretty easy.  Don't know much about ISATAP (yet).

[jimb]

Why did you have to set up a tunnel from the W2000 machine?

Are they on completely different LANs?  My impression was that the WS2008 box and the other machines were on the same LAN and you were using the routed /64 on that LAN.  In that case they should have all been able to speak to each other directly over ethernet using IPv6.

If they're separated by an IPv4 only router, then you'd either need to tunnel, or use something like ISATAP to route IPv6 over an IPv4 LAN infrastructure (ISATAP basically works by using IPv4 as a link layer protocol for IPv6).  You'd also need to request a routed /48 from HE, since the routed /64 is only good for one LAN and you'd need more subnets.

I guess my ignorance is showing--I thought that my LAN was not IPv6 capable.  The 5 machines are connected together via a D-Link Gbit Switch.  If Ethernet is IPv6 compatible, then I guess the D-Link Gbit Switch should be too, so I can just remove the tunnel between the WS2008 and Win2000 Server machines.  That would be good--less bottleneck.  I'll try it.  Thanks for the heads up.

Aside, v6v4 tunnelling is pretty easy.  Don't know much about ISATAP (yet).

Yep.  IPv6 is just another layer 3 protocol.  Just like IPv4.  It will run on the same transports as IPv4.  Well, except for ones specifically designed for IPv4.    

But it'll run along side IPv4 on Ethernet with no problems.  The only difference in the enet packet is the ethertype, which is set to 0x86DD instead of 0x0800.  IPv6 also doesn't have broadcast.  Only multicast.  And it doesn't use ARP, but a similar mechanism based on multicast called Neighbor Discovery.

ISATAP is only needed in a situation where you have multiple LANs connected by an IPv4 only router(s).  The preferable way would be to simply enable IPv6 routing on your router.  But if you can't do that, ISATAP is one way you can get around it.

In your case you only have a single LAN, so you don't have to worry about it.

[dawkco]

Well, after all that, and getting the Routed /64 to work properly, I'm finding that the IPv6 support in Windows Server 2003 and IIS 6 is unacceptable (and Windows 2000 Server worse yet).  Windows Server 2008 IPv6 functionality is quite good, with the exception that they did not include an updated SMTP Service with IIS 7.  Instead, they included the old version SMTP Service from IIS 6 which has no support for IPv6 at all.

For anyone wondering about the details, the following document spells it out:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1ecff3af-36c2-41b5-957a-8bcc6fac8abc.mspx?mfr=true

[dawkco]

I still have one issue left with this Routed /64.  For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address.  However, if I connect from one of the other machines on my network, the NIC address of that machine is detected as the Source address of the connection as it should be.  The packets are being routed.

This is a problem for the machine with the tunnel endpoint--the machine's NIC has a public IP in the Routed /64 that is registered in DNS and needs to be recognized as such.  I didn't configure a DNS host record for the tunnel endpoint, and I don't think I can or should because it's not delegated to my DNS zone.

I've verified this on more than one remote site.  One example is:  http://www.apnic.net/, where they display the following--"Your IP:  2001:470:1f04:a85::2".  That's my local tunnel endpoint.  My NIC address in the Routed /64 is:  2001:470:1f05:a85::6.
 

Any ideas?

[cholzhauer]

I didn't configure a DNS host record for the tunnel endpoint, and I don't think I can or should because it's not delegated to my DNS zone.

Correct.

For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address

I haven't heard of that happening before; the machine my tunnel is hosted on will display the assigned address when I ping something or even do a traceroute, so I assume it would browse the web the same way.  It almost sounds like something is incorrect in your netsh setup.  While you were poking around, did you find any option to tell Windows to prefer one address over the other?

[jimb]

Actually that's pretty normal, at least on Linux.  I would think windows would work similarly  

Typically if you're connecting from a system with more than one IPv6 address, it will use the IPv6 address of the NIC through which the route to the destination is pointing (that's true for IPv4 too).  In this case, since the tunnel is the route to the internet on that machine, any internet site accessed from that machine will use the tunnel IPv6 address.

The other hosts use their LAN NIC IPv6 address since it's the only one they have, and the routes for everything IPv6 is through that NIC.

You may be able to play around with prefixpolicy to have it use the NIC IPv6 as the preferred source (netsh int ipv6 set prefixpolicy).  If you google around you'll see some examples.  (EDIT2: actually, I'm not sure if this will work in the case of multiple interfaces.  I think the routed interface address always takes precedence.  I think this is more for picking a source when there's multiple IPv6s on the same interface.  So prefixpolicy may not work for this at all.  I'm not absolutely sure though).

Another way to do this is to specify the source address to use via a cmd line option or configuration file option if the particular piece of software has such an option to do that.

EDIT: Here's a CG article on it:  http://technet.microsoft.com/en-us/library/bb877985.aspx

[dawkco]

For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address

I haven't heard of that happening before; the machine my tunnel is hosted on will display the assigned address when I ping something or even do a traceroute, so I assume it would browse the web the same way.  It almost sounds like something is incorrect in your netsh setup.  While you were poking around, did you find any option to tell Windows to prefer one address over the other?

I'm thinking you are probably not using your host as a router for other machines on your LAN the way that I am and that's the difference.  While searching, I found another post on this forum by a user having the same problem.  Although he was not routing for other machines, he was trying to use the Routed /64 on the same machine where the tunnel was installed.

The following command is supposed to provide Source address selection capability, but it doesn't seem to work in my case:

netsh int ipv6 set prefixpolicy [prefix] [preference] [label]