Hi vishal, I agree with Stig. ND processing happens after the the tunnel-endpoint decapsulates the packet. when u mean ND here i guess u are talking abt ND being multicasted/unicasted on the tunnel link. In this case the ND packet's src address cld be link-local of the tunnel end-point. As far as IP layer tunnel interface is treated as much like any other physical interface. So if ND is being generated at tunnel interface then ND is encapsulated inside another IP packet and sent across multiple hops to the tunnel destination which logically appears to be the "on-link" as far as tunnel interface is concerned. So the tunnel-endpoint decapsulates the outer IP and the ND packet processes it as though it recvd the packet from an "on-link" node. But no ND packet recvd by router on *any interface (tunnel or physical)* is *forwarded* to any other interface (tunnel or physical). its processed locally only. regards radhakrishnan The ND is in fact processes, just like it would be on another link. So the packet will be decapsulated revealing the ND content. Next the router will process it, but not forward it. If you send packets to a link-local unicast (also multicast) address on the tunnel, it is only for the tunnel, that is only for the link.You are right that the tunnel link might be many hops in the physical topology, but so what? They would still remain on the tunnel link.BTW, an ND message as Pekka stated earlier can be sent over a tunnel.Yes"The ND packet is not forwarded outside of the link" I know in the RFC4213, "Security consideration section", we state less generically what I have stated below.What exactly is the problem? Are you saying that packet may be forwarded off the link? If you agree that it stays on the link, why is there a problem with doing ND? StigThanks again, Vishwas -----Original Message----- From: Ole Troan [mailto:[EMAIL PROTECTED]] Sent: Monday, November 28, 2005 11:55 AM To: Vishwas Manral Cc: Stig Venaas; IPv6 Subject: Re: draft-ietf-ipv6-2461bis-05 Vishwas,You said "There is no difference between a tunnel link and any other link media I think." That is the exact issue in my case for ND messages. If we just send a packet tunneled, the TTL check for ND messages fails as we can send a packet from multiple hops away by just adding another layer of encapsulation.the ND hop limit check does not fail. the ND packet is not forwarded outside of the link. the tunnel link that is.That is the reason I suggested the text "The default behavior SHOULDbeto not allow ND packets over tunnels, unless explicitly soconfigured." I disagree with this proposal. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 ---------------------------------------------------------------------------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- |
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------