Hi Shree,
On 10-09-09 06:23 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
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..
The goal is to use some sort of indication from the AN as to when the
DSL link is up or down (perhaps using ANCP as Woj suggested) to
determine when to start and stop sending periodic RAs.
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.
Depends on the mechanism you use to distribute the unsolicited multicast
RAs. The scheme I was thinking of for the next version of the draft does
not have this issue. There will be one multicast RA per subscriber line
and not per subscriber device.
Is there a need to relax MinRtradvInterval requirement for L2Unicast messages ?
I am not sure there is a need to do that. For WiMAX (16ng) it was
necessary to do that in order to avoid waking up the dormant nodes. In
this case the clients will most likely not go dormant.
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.
The MAC address of the client is used as the destination address only
for the solicited RA and does not need to be remembered for future use.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
