[40847] in North American Network Operators' Group
Re: Ethernet NAPs (was Re: Miami ...)
daemon@ATHENA.MIT.EDU (Antony)
Thu Aug 23 13:02:32 2001
Date: Thu, 23 Aug 2001 19:01:12 +0200
From: Antony <antony@phenome.org>
To: RJ Atkinson <rja@inet.org>
Cc: Nanog <nanog@merit.edu>
Message-ID: <20010823190112.C8354@xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20010823115916.00a97140@10.30.15.2>; from rja@inet.org on Thu, Aug 23, 2001 at 12:04:36PM -0400
Errors-To: owner-nanog-outgoing@merit.edu
On Thu, Aug 23, 2001 at 12:04:36PM -0400, RJ Atkinson wrote:
> At 11:37 23/08/01, Antony Antony wrote:
> >for those who interested in IPv6, Path MTU Discovery is not
> >in IPv6 stack. To have end to end jumbo frames in native v6
> >we NAPs in the path should support jumbo frames.
>
> More precisely, with IPv6 networks, either:
Sorry. I ment to say routers don't perform fragmentation of packets they're
forwarding. If a packet is to be forwarded onto a link whose
link MTU is less than the size of the packet, the node
must discard the packet and send an ICMP Packet Too Big message to
the packet's Source Address. ICMP error message also contains
MTU of the link. Host can retransmit with size obtained from the ICMP message.
To have jumbo frames in IPv6 from end to end and path is via NAP,
NAPs should support it. Or am I still mistaken ?
> [Source: RFC-2460, Section 5, Page 24]
Same RFC section 4.4 and 4.5
-antony
