Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard

From: Scott Bradner <[email-masked]>
Date: Sun, 6 Jun 1999 08:23:28 -0400 (EDT)

> No. The difference is that with encapsulation the source address refers
> to the encapsulator. Thus it should be able to interpret the ICMP packet too
> big and do the right thing.

but the actual source will still have to shrink the MTU and the 
encapsulator has to return a packet too big to the actual source
(or next level in encapsulator) with the correct - corected for
encapsulation - mtu

I seem to be missing something because that seems like the same
thing that header inserters have to do

Scott
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 6 Jun 1999 11:05:14 -0700 (PDT)

> (or next level in encapsulator) with the correct - corected for

Yes, and it does this because it is receiving an ICMP packet to big
from the encapsulator specifying what packet the source should
use. Thus it is up to the encapsulator to ensure that the tunnel
behaves like a pt-pt link with a limited MTU. This is done by 
taking the ICMP "packet too big" messages arriving from routers
inside the tunnel and using those to determine the tunnel MTU.
Then the tunnel MTU will be reflected in the ICMP packet too big
that the encapsulator sends to source of the packets.
The mechanism is decribed in section 8.1 in rfc 2473.

> thing that header inserters have to do

An example might help.
1. The sender A sends packets that are 1400 bytes large.
2. The node B in the network inserts an additional 200 bytes of IPv6 
   extension headers.
3. This causes a router (C) where the mtu is only 1500 bytes to send back
   an ICMP packet to big to ***A*** saying 'max mtu is 1500 bytes'.
4. A receives this and records the path mtu as 1500 bytes.
5. A continues to send the 1400 byte packets since they are smaller than
   the path mtu.

Since the header inserter (B) doesn't receive the ICMP packet too big
it can't modify its content.

In contrast with tunneling you get:
1. The sender A sends packets that are 1400 bytes large.
2. The node B in the network adds a outer IPv6 header with additional 
   200 bytes of IPv6 extension headers for a total of 240 bytes. The source
   address of the outer header is B.
3. This causes a router (C) where the mtu is only 1500 bytes to send back
   an ICMP packet to big to ***B*** saying 'max mtu is 1500 bytes'.
(NEW) 4. B receives this and records the tunnel path mtu as 1500 bytes.
   I knows it added 240 bytes thus it sends an ICMP packet too big
   back to A with the mtu being 1500-240.
5. A receives this and records the path mtu as 1260 bytes.
6. A limits the size of packets to 1260 bytes.

   Erik

---

From: Peter Dawson <[email-masked]>
Date: Mon, 07 Jun 1999 18:58:54 +0400

Erik and all,

Erik Nordmark wrote:

> ......

Sorry for this dumb question. but do I understand that ,

1) the packetization layers instance gets notified of the
decreased PMTU.
2) and A retranismitts the packet to Destination (say D)
*Now * 3) D responds with a new MSS which is > PMTU.

Question(s)
1) Does  A continue sending packets at the size of cached PMTU or
at new MSS ?
2) Frenqency that A will take to check increase of PMTU ?

/pete