Subject: RE: draft-ietf-ipv6-2461bis-05

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 27 Nov 2005 22:46:55 -0800

Hi Ole,

Thanks for the comments. 

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)?
BTW, an ND message as Pekka stated earlier can be sent over a tunnel.

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

Thanks again,
Vishwas

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Nov 2005 09:45:37 +0100

> Thanks for the comments. 

I Agree with Ole on this one

> 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

> 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

---

From: "Radhakrishnan.S" <[email-masked]>
Date: Mon, 28 Nov 2005 14:49:28 -0800

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

Yes

Stig

Thanks again,
Vishwas

-----Original Message-----
From: Ole Troan [mailto:[email-masked]]
Sent: Monday, November 28, 2005 11:55 AM
To: Vishwas Manral
Cc: Stig Venaas; IPv6
Subject: Re: draft-ietf-ipv6-2461bis-05

Vishwas,

be

configured."

/ot