Am 18.06.2013 10:03, schrieb Steven Barth:
> On 18.06.2013 01:15, Thomas Bächler wrote:
> 
>> You're confusing me even more - how does the patch relate to ipv6cp?
>>
>> In ipv6cp, I am assigned a link-local address by the provider. I may be
>> wrong, but doesn't my peer expect that I use this link-local address in
>> its routing table in order to communicate with me? This means that I
>> cannot change the assigned link-local address.
> Well I'm not sure about that but that but that was not what I meant.
> Maybe my wording was a bit confusing as. IIRC pppd provides an option to
> define the local interface identifier for use in IPv6CP and is then
> hand-shaked with the peer. 

Documentation in pppd is incomplete here, at best. While I can define an
interface identifier using the 'ipv6' option, it doesn't say anything
about hand-shaking. My impression (from the wording of the
documentation) is that this is useful if you have a static local and
remote LL (know a-priori on both ends) and want to omit IPv6CP
completely (just like specifying a local and remote IP for IPv4).

In case there is a negotiation, the peer can still reject my requested
local LL, and I suspect it will do so if I want it to be 'fe80::1'
(right now, I use -H::1 on odhcp6c, which gives a nice and short address).

As I said, pppd's documentation is not very explicit on the matter. I
guess some experimentation and tcpdump'ing is in order to determine my
ISP's behaviour.

> And as we by default use the
> interface-identifier of the link-local address for the global addresses
> as well this should equally do what you want with the nice side-effect
> that the interface identifier of the LL-address matches those of the
> global ones.

The point of my patch was that we are not forced to do that. As long as
we perform DAD (which the kernel does automatically), we do not violate
RFC 4862 by choosing whatever interface identifier we want (I used the
term hostid in the patch, but I just noticed that the RFC refers to
"interface identifier" instead).

Another point of my patch is that it takes the path of least resistance:
Instead of messing with the pppd negotiation, it applies its settings at
a point where there is no negotiation and a large degree of freedom.

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to