Gert Doering <[email protected]> writes: > On Tue, Jun 18, 2013 at 11:35:41AM +0200, Thomas Bächler wrote: >> 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).
Just for the record: You can NEVER omit the NCP. Omitting it means that you don't run that protocol over the PPP session. This is a basic PPP concept. > That interface identifier is used for the IPv6CP handshake - it's what > the client proposes, and the server side can then accept it, or assign > something else. DSL providers usually accept, 3G providers usually > reject... Yes, but there can be good reasons for DSL providers to reject as well. When playing with the local DHCPv6 server on Juniper ERXes we discovered that they use the peer ifid as a hidden key in their lease database in addition to the DUID. This meant that a bouncing PPP session with a newly generated ifid was unable to reuse the same DHCPv6 prefix until the old lease expired, even if the DHCPv6 client (as identified by DUID) was the same. Requiring all users to configure a static ifid is impossible, so we push static ifids for PPP users with static prefixes from the ISP end. Meaning that we have to reject the peers choice. >> 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. > > I think this change is useful (without having looked at the actual code), > for exactly these reasons. With the IPv6CP handshake, you'll arrive at > something the provider controls - but then in the /64 that is announced > by RA, you can choose whatever host id / interface identifier you want, > and I can see people wanting to use something easy to type and remember, > like "::1". I must be missing something here... Exactly how do you communicate an interface identifier via RA? Bjørn _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
