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

From: "Radhakrishnan.S" <[email-masked]>
Date: Fri, 18 Nov 2005 11:30:54 -0800

Hi vishal,
 I had a doubt, is it the case in current implementations that we not  allow 
tunneled packets to be received on a node, if the tunneling from a
 source address is not explicitly configured.
 => If it is 6to4 or ipv6-in-ipv4 thats the case. Thats what pekka also 
meant. tunneled packet's outer src address is validated against the tunnel's 
configured destn address.

 If not should we make it a default behavior that ND packets are not allowed 
inside a  tunneled packet, unless it is explicitly so configured.
 => That shld be fair.

> regards
> radhakrishnan
> Thanks,
> Vishwas
> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, November 17, 2005 4:10 PM
> To: Vishwas Manral
> Cc: IPv6
> Subject: Re: draft-ietf-ipv6-2461bis-05
>
> On Thu, 17 Nov 2005, Vishwas Manral wrote:
>>   By setting the Hop Limit to 255, Neighbor Discovery is immune to
>>   off-link senders that accidentally or intentionally send ND
> messages.
>>
>> However if we send a basic ND message in IP-in-IP tunneled packet and
>> send the packet across, we can easily send ND messages off-link. A
>> solution I can think of is that by default we SHOULD NOT allow ND
>> packets inside tunneled packets unless explicitly configured to do so.
>>
>> Am I missing the point?
>
> How would those tunnel packets be decapsulated?  They're part of a
> tunnel (be it a 6to4 tunnel, IPv6-in-IPv6 point-to-poin tunnel, etc.).
> If they're part of the tunnel, they must be processed (because you
> should be able to run neighbor discovery on top of such tunnels).  If
> the host has no matching tunnel, the packet needs to be discarded.
>
> It's up to the tunneling mechanism to do appropriate verifications if
> necessary.  See RFC3964 section 4.1.1 and 4.2.1 for examples.
>
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------