On Mon, 28 Nov 2005, Ole Troan wrote:
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 aw
Vishwas,
On Nov 28, 2005, at 5:49 AM, ext Vishwas Manral wrote:
Hi folks,
To summarize the discussion we have had on and off the list, I have
put
in a short draft.
Do let me know if you have any comments or suggestions for the same?
The chairs discussed this draft and conclude that it is
Hi Vishwas,
NAT-PT is not the only middlebox effected by this phenomenon. Other middleboxes
effected would include NAT-PTs, firewalls, secure VPNs and a number of policy
based devices. All these middleboxes should be required to process fragments
that arrive out of order and assemble the fragments
Hi folks,
To summarize the discussion we have had on and off the list, I have put
in a short draft.
Do let me know if you have any comments or suggestions for the same?
Thanks,
Vishwas
==
Routing Working Group
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
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 decapsulate
On Sun, Nov 27, 2005 at 08:00:32PM -0800, Vishwas Manral wrote:
> Hi Fred,
>
>
>
> Good point. I agree, however a bigger limit would provide more
> protection, besides a lot of extension headers may not be valid in most
> cases, so TCP headers would come within the 800 bytes. Having a
> configu
