# [SOLVED]: Forcing use of a specific IPv6 address

## ipic

Just getting into IPv6, so forgive the noob question.

I have set up a Gentoo host to configure its IPv6 addresses as follows:

```
..snip from /etc/conf.d/net..

...

config_eth0="null"

config_eth1="null"

bridge_br0="eth1

eth2"

config_br0="192.168.1.11/24

2001:08B0:FB5E::11/64"

routes_br0="default via 192.168.1.5

2001:08B0:FB5E::2"
```

This appears to work correctly:

```
ian2 init.d # ifconfig br0

br0       Link encap:Ethernet  HWaddr 00:1e:8c:bf:75:20  

          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: 2001:8b0:fb5e::11/64 Scope:Global

          inet6 addr: 2001:8b0:fb5e:0:21e:8cff:febf:7520/64 Scope:Global

          inet6 addr: fe80::21e:8cff:febf:7520/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:5064 errors:0 dropped:0 overruns:0 frame:0

          TX packets:2251 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:987768 (964.6 KiB)  TX bytes:259634 (253.5 KiB)
```

When I visit an Apache site on another Gentoo box on my local subnet, I can see that my manually set IPv6 address is being used:

```
... snip from apache access log ..

2001:8b0:fb5e::11 - - [13/Apr/2010:20:46:11 +0100] "GET / HTTP/1.1" 304 -

2001:8b0:fb5e::11 - - [13/Apr/2010:20:46:11 +0100] "GET /Banner_Mail.jpg HTTP/1.1" 304 -
```

This is the behavior I want, since it helps with Apache log analysis (reverse lookups give my machine name because I've set DNS up with reverse PTR records).

However, when I go "outside" to http://ip6.me (as an example), the addressed used is the auto configured IPv6 address:

```
 lynx http://ip6.me

...

You are connecting with an IPv6 Address of:

   2001:8b0:fb5e:0:21e:8cff:febf:7520

...
```

What I would like to do is force the host to use the 2001:8b0:fb5e::11 address as the default source address, regardless of destination. Is this possible?

As a follow up question, why is 2001:8b0:fb5e::11 used on the local subnet, but 2001:8b0:fb5e:0:21e:8cff:febf:7520 used when routing out to the Internet?

Thanks

IanLast edited by ipic on Wed Apr 14, 2010 4:14 pm; edited 1 time in total

----------

## dwbowyer

I'm not too familiar with IPv6, but have been doing reading on it recently.

Are you aware that the first half of the IPv6 address is the MAC address of the device?

I can only guess that bridging on your local network is allowing the different address,

but that to the rest of the world, that interface is known by it "true" identity.

Sorry I don't have links handy. Googling should turn up more info.

EDIT: Just to be clear, I'm saying it's the latter half of the IPv6 address you can play with.

First half is and always will be hardware defined under IPv6.

----------

## ipic

 *dwbowyer wrote:*   

> Are you aware that the first half of the IPv6 address is the MAC address of the device?
> 
> I can only guess that bridging on your local network is allowing the different address,
> 
> but that to the rest of the world, that interface is known by it "true" identity.

 

Yep - you can figure out the MAC relationship by just looking at the address   :Shocked: 

So, what defines the "true" address in your book then? 

I would have thought it was the manually configured global address. Your idea seems a bit backwards to me, ie the auto configured address is the "true" address? Why, and what decides that? If you were correct why would the "fe80::" address not be used for the bridged network - its "truer"?

Oh, and the reason I'm here is that I've been Googling for a week!

I don't think your statement about a part of the address being hardware defined is correct by the way. There is an option to form the lower 64 bits from a hosts MAC address - but that is an option, not a rule. Ref CISCO manual for that one.

Regards

Ian

----------

## ipic

Disabling auto configuration and stopping the accepting of router announcements has provided some education, and achieved the effect I want. May be overkill though.

To do this, I put a bunch of sysctl settings in /etc/sysctl.conf:

```
net.ipv6.conf.default.accept_redirects = 0

net.ipv6.conf.default.forwarding = 0

net.ipv6.conf.default.accept_ra = 0

net.ipv6.conf.default.accept_ra_defrtr = 0

net.ipv6.conf.default.accept_ra_pinfo = 0

net.ipv6.conf.default.autoconf = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv6.conf.all.forwarding = 0

net.ipv6.conf.all.accept_ra = 0

net.ipv6.conf.all.accept_ra_defrtr = 0

net.ipv6.conf.all.accept_ra_pinfo = 0

net.ipv6.conf.all.autoconf = 0
```

Probably overkill - some experimentation seemed to show that the default changes would be enough. Rebooted to check that it all gets applied.

Having done that, the host could no longer find its way out to the Internet - caused by disabling accept_ra I think.

So, change to the /etc/conf.d/net setting to set up a explicit route out:

```
routes_br0="default via 192.168.1.5

2000::/3 via 2001:08B0:FB5E::2"
```

After that, the br0 interface just had one global scope address:

```
ian2 ~ # ifconfig br0

br0       Link encap:Ethernet  HWaddr 00:1e:8c:bf:75:20  

          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: 2001:8b0:fb5e::11/64 Scope:Global

          inet6 addr: fe80::21e:8cff:febf:7520/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:11392 errors:0 dropped:0 overruns:0 frame:0

          TX packets:4319 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:1690225 (1.6 MiB)  TX bytes:546405 (533.5 KiB)
```

and accessing http://ip6.me showed the manually configured address

```
You are connecting with an IPv6 Address of:

                   2001:8b0:fb5e::11
```

I still don't know what is driving the choice of source address when auto configuration is enabled, and it still seems wrong to me that an auto configured address should be used instead of a manually configured one - but in my case disabling auto configuration solves the problem.

Still be interested in hearing if anyone actually knows what is going on here of course, but "solved" as far as my issue is concerned.

Regards

Ian

----------

