В письме от 14 мая 2013 21:21:06 пользователь Ondrej Zajicek написал:
Good point.
As for me (and from point of our helpdesk) this solution has one big
disadvantage: traceroutes, from external networks to customer network(s) will indicate missing hop - customer gateway, configured with link-local address on its WAN interface (ICMP Destination unreachable dropped by our access server).
AFAIK this should not be a problem - In IPv6, gateway should use some other global address (like one from /64 used on local network) as a source addr for ICMP answers (or other its traffic), so there would be all hosts in the traceroute output.
Really. This is true (tested using script in attachment). One big advantage with LL addresses is support on default kernel without extra patches to extend Proxy NDP functionality to degree of Proxy ARP in IPv4. Modifications done by these patches are very likely to be declined by upstream because they at least puts interface in mode where network driver accept all multicast (see ip-link(8) allmulticast interface flag) traffic and do few modifications to IPv6 stack to bypass checking of multicast IPv6 address (used for ND). Later code performs uRPF checks to prevent address spoofing and thus filling neighbour cache with entries in STALL/DELAY state (however this is still possible with LL) and other checks before reply to proxy (actually behavior mostly identical to Proxy ARP). However this activated only when proxy_ndp switch is on. Without patches each proxified address must be configured explicitely using ip-neighbour(8). There is no problem to proxy address used as gateway on CPE, but connectivity between addresses, allocated to CPE INET interface broken. However some minor circumstances are still valid (customer, connects PC directly to test their connectivity at least). Using LL addresses looks more robust and convenient way. Thanks.
There is other minor cases where link-layer address usage is not best choise: - some users like to connect their PC directly to Internet (:-)) (or at
least do this to test connectivity and speed).
- some "network" OS'es in network equipment does not allow (or make things a> bit complicated) setting link-layer addresses.
BTW, choosing CPE properly supporting IPv6 (including prefix delegation) seems to be a nontrivial problem itself. One of my ideas about how to provide IPv6 in a small wireless ISP was to configure clients' prefixes in CPEs and use RIPng in CPEs to propagate it to an ISP router (to get proper link-local next-hops here), with some validation in ISP router, of course.
Looks working (again, CPE equipment and their RIPng implementation:-)). However there other cases: - security, RIPng incecure, i can suppose there is no CPE with security option implemented (HMAC-MD5,...) - filtering on ISP router (even with BIRD this adds more overhead) - additional multicast on link (this gives unecessary multicast on large L2 segments) - overall administrative overhead and troubleshooting by adding dynamic routing part to customer connection. -- SP5474-RIPE Sergey Popovich