Suresh, There are still unanswered questions..
Comments inline ... -- Shree >-----Original Message----- >From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] [..snip..] >> 1. Prefix Lifetime Binding/Expiry.. >> >> Unlike DHCP there is no mechanism with SLAAC for a host (client) to >> renew >its address/prefix binding. >> Relying on host to send a router solicitation (as a keep alive) toward >> edge >router is not a viable option. >> >> RFC 4861 (section 6.3.7 ) >> >> Router solicitation "may" be sent after following events >> >> - The interface is initialized at system startup time. >> - The interface is reinitialized after a temporary interface >> failure or after being temporarily disabled by system >> management. >> - The system changes from being a router to being a host, by >> having its IP forwarding capability turned off by system >> management. >> - The host attaches to a link for the first time. >> - The host re-attaches to a link after being detached for some >time. >> >> In such an situation what is the mechanism for edge router to time out a >binding from its database ? > >Right. The BBF deployment will have periodic RAs sent to the client with >the PIOs after the initial RS is sent. The client does not need to >periodically retransmit the RSs. [Shree] The draft requires edge router to remember hardware address of each node to unicast the RA's. With no reliable feedback from end device to signal if it's on or off the network, how long should the edge router remember the hardware address to LIO Prefix binding ? Time out's are not an option since device may not send another RS till it resets etc. The most logical approach would be for edge router to use Neighbor Discovery before timing out the binding. But even that's not 100% conclusive e.g. when a DSL link is down, ND will fail and edge router will timeout it's binding However end point will still have the binding, and with no router advertisement will eventually expire the address. But there is nothing in spec which says end point should resend a RS to re-create this binding.. a catch-22 sort of situation.. >> 2. Sending Unsolicited router advertisements >> >> >> With max router lifetime of 9000 sec (RFC 4861) and MinRtradvInterval >(3sec - RFC4861) >> >> Only 3000 unsolicited RA's can be sent before router lifetime expires >> (this >may restrict the scaling). > >Yes. It does comply to section 6.2.4 of RFC4861. The scaling issue is >the same as we face with 1:1 VLANs where we need to send one multicast >RA per subscriber premise. [Shree] The draft callsfor one RA to be unicast per IPv6 end node (L2 hardware address), so if There are 6 devices connecting from a subscriber premises (RG is bridged) the scaling is reduced Compared to 1:1 VLAN. Is there a need to relax MinRtradvInterval requirement for L2Unicast messages ? >> >> 3. Denial of Service attack >> >> - Since bindings can't be timed out is the edge router susceptible to a >denial of service attack based >> on changing source hardware address of router solicitation message. >> >> This can be a distributed DoS, or >> a delayed DoS e.g. where a malicious node sends a router solicit (with 8 >different MAC addresses) waits for 30 mins >> (so access node times the 8 MAC's out of it's FDB) then sends another 8 >router solicits and so on so forth >> Till the edge router runs out of resources.. > >The subscriber is identified by the line on which the device connects to >the access node. In this case, all the 8 MAC addresses will end up >getting tagged with the same Line identification and will end up using >the same prefix. There will be no resource exhaustion. [Shree] The binding referred was edge router storing hardware address from each RS received. This still holds true as possible DoS attack, since there is no reliable mechanism to Cleanup MAC addressed stored to unicast the RA. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
