According to RFC 2492 SLLAO option should not be used in an ATM PVC environment, yet the NA may be transmitted as a part of DAD which is still required. Thus with this proposal we can have an ICMP error generated in a scenario where no error condition has occurred.
--- Thomas Narten wrote: > > The basic issue left is whether we should allow a > node to send an ICMP error > > due to the reception of an NA without the SLLAO. > The reason for sending the > > ICMP error is to inform upper layers that the > communication has > > failed. > > It took me a while to figure out what you are > proposing. To summarize: > in the case where where a node receives an NA > without an SLLAO, but it > is expecting an SLLAO (so it can complete the > Neighbor Cache Entry), > such a received NA is "an error". In the case where > a regular data > packet is queued pending completion of the NCE, > you'd like to be able > to send back an ICMP error indicating "dest > unreachable". Right? > > This seems like a fairly minor optimization and one > that deals with a > a potential "implementation error" (since I > understand this situation > would normally only arise of the sender of the NA > incorrectly left off > the SLLAO). If this is the case, IMO, it's not > worth modifying the > spec to allow this. Indeed, I'd have to think a bit > to convince myself > that it couldn't lead to potential cases where an > ICMP error would be > (incorrectly) sent when simply ignoring the faulty > NA is actually the > more correct response (i.e., if proxies are present > and more than one > NA is generated). > > Is this a situation that has come up in actual > testing/usage? > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
