On Monday 15 October 2012 13:31:10 Mark Smith wrote: > Hi Oliver, > > Thanks very much for your feedback. > > I think there is value in that (I think generalising is a good idea if you > > can do it), however I would be interested in some use cases where something > other than the source address prefix would be a useful discriminator. I'm > struggling to think of one right now. (It is 6.30 am which might explain it)
I'd say there will ostensibly be situations where you do not actually care about the addresses you need to trust (or may simply not know it in advance/change so often that it's an administrative nightmare) but *do* know that all traffic arriving from interface X is trustworthy, in that instance, being able to classify by ingress interface would be invaluable. Taking it to the extreme, arbitrary packet marks/tags provide a means to classify based on practically anything. Additionally, I can think of existing IPv6 implementations where there is already infrastructure for matching based on interfaces or marks but providing an in-stack table of addresses would be cumbersome. > > 2) While SLND is active, a packet that requires a solicitation MAY be > > dropped outright but can optionally be requeued/buffered etc - queue > > discipline should be considered beyond the scope of this document. > > I though about maintaining an "destination address independent" queue of > > traffic that triggered stateless neighbor discovery. I realised though I'd > then have to work out answers to things like should new packets replace old > ones, how big the queue is by default, and how it is worked out whether > a packet can be removed from the queue. I then realised that there is > probably already a queue of some form between the forwarding plane and the > control plane of the router, so I though this new queue may not be worth > the additional complexity it would create I'll review that decision though. This wouldn't necessarily require a separate queue; any dequeued packet that results in a solicitation being sent would then need to have a counter set on it to prevent it from triggering another solicitation if dequeued again and eventually get dropped - this would then also open up the option of generating an ICMPv6 error at expiry. Essentially, a change to the architecture of the queue is more along the lines of what is required as opposed to maintaining an entirely separate queue. > > One thing I'm also trying to do is keep in mind that this proposal is > > dealing with an exceptional case rather than a common case, meaning that > the mechanisms might only be rarely if ever used. So I think there is some > value in trying to keep the mechanisms as simple as possible. I'm still > having a bit of a debate with myself as to whether the trusted/untrusted > prefix mechanism is even necessary - to protect against the DoS it would > be adequate to just resort to stateless ND for all traffic sources once > the neighbor cache becomes reasonably near capacity. I'm definitely all for occam's razor, but I believe that being flexible is also important. The opportunistic level of complexity should be covered in the RFC and then left down to the implementor, otherwise I'd anticipate a situation where future RFCs end up being written after complex implementations have already come into existence. In other words, "attempt to cover all the bases" - providing some means of mitigating ND flooding is most certainly a Good Thing, whether it be rudimentary or everything but the kitchen sink, I would aim to set an acceptable baseline (which IMO this document has certainly already achieved) and also give opportunity & suggestions for exemplary robustness. > > > I am also pondering the possibility of securing the on-link side by way of > > ND > > > > cookies (with a prerequiste being that the subnet size is at least /64) > > > > Essentially, while using SLND, a node would generate a neighbour > > solicitation for unknown on-link hosts using an algorithmically > > calculated source address resulting from a hash operation over a > > node-unique seed, the target address contained within the advertisement > > and the IPv6 header destination address. > > > > Thus when receiving a neighbor advertisement, the node can simply hash the > > data in order to verify if the advertisement is spurious or not. The node > > must not bind to nor answer solicitatation for these calculated > > addresses. This will ensure that in the event of a duplicate address, ND > > for the duplicate would not result in a false discovery. > > > > > > I like that idea because it doesn't require changes to hosts. However I'm > > not sure I understand how the neighbor advertisements would be sent back to > the router issuing the neighbor solicitations? Where you think they would > be multicast, so that the hash source address didn't have to be used to > unicast them back to the router, avoiding the unicast ND related issues? When sending an ICMPv6 neighbour solicitation, if there is an applicable data- link layer, the sending host can indicate the appropriate L2 address as an added option to the ICMPv6 message - this results in the solicited node sending the neighbor advertisement response to that indicated data-link layer address, maintaining the IPv6 layer address as destination - however, if the node is unknown, without this option included, the L2 response destination will be taken from the L2 source of the solicitation. Were it the case that sending a neighbour advertisement depended on already knowing the L2 address of the querier, IPv6 would have a serious chicken & egg problem :) Kind Regards, Oliver -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
