HOWTO: Learning recursive routes from kernel protocol

[Sergey Popovich]

В письме от 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipv6-deployment-using-ll-addresses.sh
Type: application/x-shellscript
Size: 3824 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130515/3c9a0469/attachment-0001.bin>