How to add/set route from Routed /64 to Tunnel Endpoint?

[dawkco]

...
Typically ... the IPv6 address of the NIC through which the route to the destination is pointing ...  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.
...
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

I tried:  netsh int ipv6 set prefixpolicy <prefix> <preference> <label>, and it didn't work.

I read the technet article and RFC 3484 Default Address Selection for Internet Protocol version 6 (IPv6).  If the Windows implementation provided the Administrative Override option allowed in the RFC, it would work, but the Windows implementation differs slightly from the RFC (as usual).  In the Windows implementation, the preferred Source address for a routing interface is the next hop address from the origin and it wouldn't allow me to override that.  It didn't complain if I tried, but it just had no effect.

This is weird.  The tunnel interface is like a virtual interface that's spliced into the IPv4 side of the physical NIC, but the IPv6 side of the physical NIC is a separate routing interface where the hidden and unstated next hop address is the local side of the tunnel.  I don't see how I can use this.  I need to be able to use the Routed /64 address that's registered in DNS as the Source address.

I don't know of any command-line or configuration file options for Source address selection (other than prefixpolicy).  Do you?

[jimb]

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]

Yeah if you read RFC-3484, you'll see that the "label(S)==label(D)" step is way down on the list, and the "prefer outbound interface IP" is ahead of it, so it never gets to that step in the case of multi-interface machines.  I tried to note that in my last message.

The prefixpolicy RFC-3484 source address selection stuff only seems to apply when you have multiple IPv6 addresses on the same interface.  When everything else in the list is a tie, then you can preference one source address over another using prefixpolicy.

The only surefire way to do it is to actually specify which source address to use.  A lot of software supports this, but not all.  I'm not sure if theres any way to make IE or FF use a particular source IP.  But I'd think most system services could be manually bound to use a particular address for outbound initiated connections.

Anyway, on my IPv6 router, it behaves the same way.  If I want it to use my LAN interface address, I have to tell the particular piece of software to use the particular interface or address.  This always overrides prefixpolicy, etc.

[dawkco]

Yeah if you read RFC-3484, you'll see that the "label(S)==label(D)" step is way down on the list, and the "prefer outbound interface IP" is ahead of it, so it never gets to that step in the case of multi-interface machines.  I tried to note that in my last message.

The prefixpolicy RFC-3484 source address selection stuff only seems to apply when you have multiple IPv6 addresses on the same interface.  When everything else in the list is a tie, then you can preference one source address over another using prefixpolicy.

The only surefire way to do it is to actually specify which source address to use.  A lot of software supports this, but not all.  I'm not sure if theres any way to make IE or FF use a particular source IP.  But I'd think most system services could be manually bound to use a particular address for outbound initiated connections.

Anyway, on my IPv6 router, it behaves the same way.  If I want it to use my LAN interface address, I have to tell the particular piece of software to use the particular interface or address.  This always overrides prefixpolicy, etc.

Actually, I only have one NIC interface (enabled) on this machine, but if you mean multiple interfaces in the sense of virtual and pseudo interfaces along with the NIC, then I see your point.  And, oh yeah (of course), I will be specifying which address(es) to bind listening sockets to in my services, so source address selection shouldn't be an issue for my listening services.

My point about Windows implementation of RFC 3484 was that, regardless of the ordering of the steps in the source address selection algorithm, the administrative override should take precedence.  Anyway...

HOWEVER--I THINK I HAVE IT FIXED!  Or at least working the way I want it to.  Here's what I ended up with (and don't tell me I'm wrong cuz I'm not listening  ;D ).

1.  I added a IPv6 Default Gateway Route from the NIC to the remote tunnel endpoint IPv6 address.
2.  I deleted the local tunnel endpoint IPv6 address from the tunnel interface.

Now, I can ping out, the outbound ping source address defaults to the NIC Routed /64 address, and remote sites detect my (source) address as the Routed /64 address.  Here's what the route table looks like:

netsh interface ipv6 show route

Publish  Type      Met  Prefix                    Idx  Gateway/Interface Name
-------  --------  ---  ------------------------  ---  ------------------------
Yes      Manual    1    ::/0                       10  2001:470:1f04:a85::1
Yes      Manual    1    ::/0                       15  2001:470:1f04:a85::1
No       Manual    0    ::1/128                     1  Loopback Pseudo-Interface 1
No       Manual    0    2001:470:1f04:a85::/64     15  IP6Tunnel
No       Manual    0    2001:470:1f05:a85::/64     10  Local Area Connection
No       Manual    0    2001:470:1f05:a85::6/128   10  Local Area Connection
No       Manual    0    fe80::/64                  10  Local Area Connection
No       Manual    0    fe80::/64                  15  IP6Tunnel
No       Manual    0    fe80::5d1:3ef0:29cf:740d/128   10  Local Area Connection
No       Manual    0    fe80::4571:e519:fffa:2d7f/128   15  IP6Tunnel
No       Manual    0    ff00::/8                    1  Loopback Pseudo-Interface 1
No       Manual    0    ff00::/8                   15  IP6Tunnel
No       Manual    0    ff00::/8                   10  Local Area Connection

And, here's the prefix policy table.  Note that I did update it, but it never made a difference until I made the changes in the route table and interface addresses.

netsh interface ipv6 show prefixpolicies
Querying active state...

Precedence  Label  Prefix
----------  -----  -----------
        50      0  ::1/128
        40      1  ::/0
        30      2  2002::/16
        20      3  ::/96
        10      4  ::ffff:0:0/96
        40      1  2001::/16

I hope that's the end of this issue as I need to start searching for services software that supports IPv6 better than the stuff that comes with Win2K and Windows Server 2003.  Oh, and an SMTP server for Windows Server 2008.

I'll reboot and make sure this is all still working afterward.  If so, I'll post a final confirmation that this is solved.

Thanks for your help and input.

[dawkco]

I was joking when I said "don't tell me I'm wrong."

I was wrong--that last setup didn't work reliably.  It seemed fine for a while, but some continuous testing revealed that about every 5 minutes or so, the Routed /64 address assigned to the NIC became unreachable for a minute or two, then the cycle would repeat.  I couldn't even ping the address from itself during these episodes.

Back to the drawing board...

[dawkco]

from 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

... It almost sounds like something is incorrect in your netsh setup...

I think you're right.  I decided to use:
netsh interface ipv6 reset
and start over.

I'm wondering--is the following recommended command really necessary?
netsh interface teredo set state disabled

[cholzhauer]

I'm wondering--is the following recommended command really necessary? netsh interface teredo set state disabled

Necessary?  No.  Recommended?  Definitely

[dawkco]

I'm wondering--is the following recommended command really necessary? netsh interface teredo set state disabled

Necessary?  No.  Recommended?  Definitely

Ok, I see it now--Teredo is for tunneling through NAT devices, which doesn't apply here.  No sense cluttering the setup with potential conflicts when it's not needed anyway.  Thanks.

[dawkco]

Ok, after a reset and removal of the tunnel and routed /64, followed by a reinstall and setup of same, everything seems to be working.  However, I still see the wrong Source address when I connect to a remote site--it's the local tunnel endpoint address instead of the routed /64 address assigned to the NIC.

I really need to find a work-around for this...

[dawkco]

I've got a work-around that seems to be working and is stable, but it has a (hopefully) trivial drawback.  Outbound and inbound pings work; outbound tracert's work fine, but inbound tracert's can't resolve the one hop at the tunnel, although inbound tracert's do continue through successfully to my routed /64 NIC.

The settings are similar to my last failed attempt:

1.  Added a Default Gateway route from the routed /64 NIC to the tunnel remote endpoint IPv6 address.
2.  Deleted the tunnel local endpoint IPv6 address from the tunnel interface.

The differences in my setup this time are noted below:

• The Default gateway routes for the tunnel and the routed /64 NIC are not Published.
• The routed /64 NIC has Advertising disabled.
• The tunnel interface has Router Discovery disabled.
• The Prefix Policy table is reset to the default values.

(I had tried the opposite route and interface settings, and had added a Source address selection rule to the Prefix Policy table, during my prior attempt.)

Other settings used that are the same this time:

• All interfaces have Forwarding enabled.

The routed /64 NIC has the following:

• Neighbor Discovery enabled
• Neighbor Unreachability Detection enabled
• Router Discovery enabled
• All other interface settings are the default values.

Here's the current route table:

Publish  Type      Met  Prefix                    Idx  Gateway/Interface Name
-------  --------  ---  ------------------------  ---  ------------------------
No       Manual    256  ::/0                       16  2001:470:1f04:a85::1
No       Manual    256  ::/0                       10  2001:470:1f04:a85::1
No       Manual    256  ::1/128                     1  Loopback Pseudo-Interface 1
No       Manual    256  2001:470:1f05:a85::/64     10  Local Area Connection
No       Manual    256  2001:470:1f05:a85::6/128   10  Local Area Connection
No       Manual    256  fe80::/64                  16  IP6Tunnel
No       Manual    256  fe80::/64                  10  Local Area Connection
No       Manual    256  fe80::200:5efe:65.168.232.6/128   15  Local Area Connection* 8
No       Manual    256  fe80::5d1:3ef0:29cf:740d/128   10  Local Area Connection
No       Manual    256  fe80::bd65:2797:80a6:39af/128   16  IP6Tunnel
No       Manual    256  ff00::/8                    1  Loopback Pseudo-Interface 1
No       Manual    256  ff00::/8                   16  IP6Tunnel
No       Manual    256  ff00::/8                   10  Local Area Connection

I noted that a couple of the interface Index values changed following a reboot after the ipv6 reset.

Here's the current Prefix Policy table:

Precedence  Label  Prefix
----------  -----  --------------
        50      0  ::1/128
        40      1  ::/0
        30      2  2002::/16
        20      3  ::/96
        10      4  ::ffff:0:0/96
         5      5  2001::/32

The prefix policy entries are just the default values.

I don't think the problem of tracert not being able to resolve the tunnel hop of an inbound trace is a big issue.  Am I wrong?

[jimb]

When I say multiple NICs I also include virtual NICs, since from a networking standpoint they're just as valid as real hardware NICs.

For services, the listen IPv6 really isn't important, since services will listen on all IPv6s by default.  If you for whatever reason don't want a service to accept connections on the Tunnel IPv6, it'd be easier to filter this with firewall rules.  The more important factor is which IPv6 that the service uses to originate connections.  For services which are "listen only", you don't have to worry.  For services such as SMTP which initiate connections, you need to specify the source IPv6 to use.

From on my understanding of RFC3484 The prefixpolicy stuff you listed wouldn't have affected source address selection as the "precedence" part is only used for destination address selection when choosing between a bunch of IPv6s and IPv4s returned by DNS.  The only factor which influences source address selection is the "label", which only applies in a tiebreaker situation once many other "tests" are passed through resulting in a tie (they're listed in the RFC in order).  It will look up the label entries in the prefixpolicy table for the source addresses and the chosen destination address, and will prefer a source address which has the same label as the destination address.  So for example, the destination address matches an entry in a prefixpolicy table which returns a label of 1, if you have an entry in there for your chosen source address which also matches a label of 1, this will cause it to use that matching source address. 

As for the routing shenanigans, I can see how that would work, but could also see how it would fail as soon as the HE side sent a Neighbor Discovery for your side of the tunnel interface.  And of course as you discovered, it will break traceroute.  It also breaks any ability to connect to the machine via the outward facing tunnel interface, which is a good thing to have in many cases.  IMHO, doing things like this falls into the area of "unnatural acts" which I tend to avoid because it almost always winds up causing problems in the end.

Personally, I'd just figure out a way to have software which initiates connections to use a particular IPv6 address to do so.  And like I said, the listening side doesn't matter, as it will answer to any IPv6 it has.  And for non-server software such as web browsers, I'm not sure why it matters which IPv6 it uses.

[dawkco]

...
For services, the listen IPv6 really isn't important, since services will listen on all IPv6s by default. ... The more important factor is which IPv6 that the service uses to originate connections.  For services which are "listen only", you don't have to worry.  For services such as SMTP which initiate connections, you need to specify the source IPv6 to use.
...
As for the routing shenanigans, I can see how that would work, but could also see how it would fail ... It also breaks any ability to connect to the machine via the outward facing tunnel interface, which is a good thing to have in many cases...

Personally, I'd just figure out a way to have software which initiates connections to use a particular IPv6 address to do so...

Unfortunately, just binding a service's outbound communications socket to the routed /64 address would not solve this problem.  On the remote end, the connection would still appear to be coming from the tunnel local endpoint IPv6 address.  When a web browser connects to a remote site, it does just that--binds a connection socket to the routed /64 address, but as the outbound packets are routed through the tunnel gateway, the IPv6 Prefix Policy source address selection algorithm causes the packets to inherit the tunnel local endpoint Ipv6 address (because it's the outbound interface).  Since the source address selection administrative override mechanism either doesn't apply or Windows IPv6 doesn't obey it, it doesn't help in this case.  As you mentioned, this is a critical issue for a service such as an SMTP Server.

Believe me, I would prefer not to use any work-around, but I don't seem to have a choice right now.  Luckily, everything is working well--better than ever in fact.

However, it appears that I will have to enable the Windows Firewall now.  The 6in4 tunnel has created a loop-hole in my layer-4 port blocking hardware firewall.  (I had read that was possible, and have confirmed it so using the HE IPv6 Port Scan.)

I must say that I am both impressed with, and grateful to HE for all of this IPv6 support.  When the IPv4 address space runs out, we'll be ready!  Thank you HE!

[jimb]

The address selection algorithm doesn't override what the software binds as a source address.  This is true in both Windows and Unixes.  The address selection thing is only for when a source IP isn't specified in the socket call (e.g. it's left as 0.0.0.0 or :: ).  Doing so is basically saying "Please fill in the appropriate IP Mr. OS."  If the source IP is already filled in by the application, it will use that source IP (IPv4 or IPv6).  In fact it will use any IP you fill in there, even one which doesn't live on the machine (this is how certain malware does things like DOS attacks and DNS cache poisoning, etc).

Thus, services like SMTP and DNS servers can be configured to connect outbound using a particular IPv4 or IPv6 address.  It's also how you can specify a source IP address in many utilities like ping, wget, ssh, etc, etc,etc.  While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.

Yes you definitely need a firewall.  I think I mentioned that in a previous post.  Setting up an IPv6 tunnel essentially opens all machines with an IPv6 address to the internet.

[dawkco]

While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.

Sounds good, but it's not what I was seeing.

[jimb]

While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.

Sounds good, but it's not what I was seeing.

Well, I can prove it.  Here's cygwin wget on my XP box.  Yes it's cygwin, but ultimately it results in a call to the windows networking API and drivers.  I added an extra IPv6 address to my interface to do this test:

Plain wget without any source address arguments:

wget -6 -O - http://ip6.me |egrep -i 2001
Resolving ip6.me... 2001:4810::110
Connecting to ip6.me|2001:4810::110|:80... connected.
<tr><td align=center colspan=3 bgcolor="D0D0F0"><font face="Arial, Monospace" size=+3>2001:db8:1234::88</font></td></tr>

And here specifying a different IPv6:

wget -6 -O - --bind-address=2001:db8:1234:0:213:ceff:fe9b:2d70 http://ip6.me | egrep -i 2001
Resolving ip6.me... 2001:4810::110
Connecting to ip6.me|2001:4810::110|:80... connected.
<tr><td align=center colspan=3 bgcolor="D0D0F0"><font face="Arial, Monospace" size=+3>2001:db8:1234:0:213:ceff:fe9b:2d70</font></td></tr>

As you can see in the HTML output (edited out a lot of junk), it sees the IPv6 as the one I set with the "--bind-address" option of wget.  

The same options works the same way on my Linux box which has my HE tunnel interface and my LAN interface.  Normally it'll connect with the outward facing interface IPv6.  If I give it my LAN interface IPv6 it uses that and ip6.me reports that as my IPv6, just as in the above test.

Try it yourself.

[dawkco]

While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.

Sounds good, but it's not what I was seeing.

Well, I can prove it...

Try it yourself.

Ah, Ok I see it now--in fact, I was logging into the forum to correct myself.  I misinterpreted the meaning of how the Prefix Policy table was implemented.

Still, an important feature of the prefix policy is the administrative override of default policies, which Windows doesn't seem to allow for.  Example:  assuming that my web browser used an unspecified address for its outbound connection, the OS should have preferred my routed /64 address as the source address when I had the following prefix policy table entries:

Precedence  Label  Prefix
----------  -----  ----------
...
        40      1  ::/0
        40      1  2001:470:1f05:a85::/64
... etc.

In other words, for any destination address, select the routed /64 address as the source address.  But it didn't work.

So, is there a wget for Windows?  I'd like to do this test myself.