On Sun, Nov 27, 2005 at 10:46:55PM -0800, Vishwas Manral wrote: > Hi Ole, > > Thanks for the comments.
I Agree with Ole on this one > Can you point me to a document which tells of the generic check at the > decapsulator, which states what you said (the decapsulator checking in > the decapsulated packet is an ND message and not processing it further)? 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? Stig > > Thanks 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 SHOULD > be > > to not allow ND packets over tunnels, unless explicitly so > configured." > > I disagree with this proposal. > > /ot > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
