Hi Thomas,
On 10-08-27 07:42 PM, Thomas Narten wrote:
Suresh,
I would not say it is a problem with the deployment architecture. As I
said in mails to Thomas and Woj, the issue occurs in other deployment
architectures that need to use different prefixes over the same shared
L2 domain (e.g. WLAN AP with 2 SSIDs mapped into 2 VLANs on the fixed
side connected to the edge router).
This is not a helpful comment.
Neighbor Discovery is simply not designed to operate cleanly in an
environment where different PIOs are advertised to different clients
over a shared LAN.
I have realized that it *does not* operate cleanly in this scenario. I
did not know it was *not designed to* operate cleanly in this scenario.
This would have been very useful information to have in the ND spec.
The fact is, any protocol is based on underlying assumptions (whether
stated explicitely or not). If you break those assumptions, but use
the protocol anyway, the protocol may not work so well any more. E.g.,
try running TCP across a path where 50% of the packets are lost due to
corruption.
The problem with the deployment architecture at issue is that it has
chosen to use RAs in such an environment.
I am really open to recommendations. What else can the network use to
not run into problems?
The fact that the same issue would occur on other deployments that
made the same (broken) assumption, doesn't somehow mean the
architecture isn't broken.
If the assumptions that the protocol designers made are not somehow
communicated, people are bound to break them and find out the hard way
(like in this case). The best insurance against this is to state the
assumptions explicitly.
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
