Hi Shree,
Thanks for the comments. Please find responses inline.
On 10-09-07 09:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
Suresh,
One of the main challenge in implementing the model proposed by the draft
is that edge router has no reliable indication if a host (once it has sent an RS)
is present on the network or not.
Please see detailed comments below..
--
Shree
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.
2. Sending Unsolicited router advertisements
Since the PIO's are specific to each end-device (RG or host) the edge
router needs to send unsolicited router advertisements to each end-device.
In this case what is the expected behavior of edge router , does it still confirm to section 6.2.4 of RFC 4861
and the bounds of delays between 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.
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.
4. What happens when a L2 MAC address is not in the FDB.
The RA's are unicast presumable to avoid them being flooded to other nodes for security reason (a node is only aware of it's prefixes).
What happens when a node who is allocated a prefix is powered off and it's link layer (MAC) address is no longer in FDB of L2 network (access node).
Is the packet flooded to all hosts/RG's ? doesn't that defeat the
purpose ?
I am working on how to tag the RAs for downstream distribution so that
the Access Node can perform this filtering. Earlier versions of the
draft had this feature but it was removed as the WG thought it was not
necessary. This would require an ND option to be allocated.
5. Creating an alternative to DHCPv6 ?
One SLAAC is defined to do functionality similar to DHCP (including per host prefixes/options)
how long before options are added so SLAAC becomes an alternative to DHCPv6 ?
The goal is not to come up with an alternative to DHCPv6. The goal is to
provide backward compatibility for IPv6 hosts that are SLAAC only.
Per host prefixes also are not new and have been used widely in
non-Ethernet networks (3GPP being a prominent one, where each mobile
will get a distinct /64 prefix).
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
