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?

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
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
--------------------------------------------------------------------

Reply via email to