Subject: PMTU dicovery

From: Syed Obaid Amin <[email-masked]>
Date: Sun, 20 Nov 2005 20:07:58 +0900

Hi
 Can intermediate routers do Path MTU discovery or the originator of packet
will do it ONLY?
for e.g. In case of VPN; can router for encapsulation do PMTU and send the
"PMTU - (size of Data used for encaspulation)" to Source so encapsulation
wont fragment the packet?
 Thanks
 Obaid Amin
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 20 Nov 2005 20:01:56 -0800

Hi Obaid,

I think we do not require sending the PATH MTU to the original source at
all. The original source when doing a Path MTU would use the tunnel and
the PMTU would correctly work (the tunnel would be another link in the
path).

Thanks,

Vishwas

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Syed Obaid Amin
Sent: Sunday, November 20, 2005 4:38 PM
To: [email-masked]
Subject: PMTU dicovery

Hi

Can intermediate routers do Path MTU discovery or  the originator of
packet will do it ONLY?

for e.g. In case of VPN; can router for encapsulation do PMTU and send
the "PMTU - (size of Data used for encaspulation)" to Source so
encapsulation wont fragment the packet?

Thanks

Obaid Amin

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 21 Nov 2005 09:36:15 -0500

Just to add to Vishwas' reply, Pekka's draft can be summarized (for
the purposes of this discussion) as follows:

1) For any tunneling technology, either the tunnel head-end has to
   be prepared to correctly respond to path MTU discovery as if the
   tunnel is itself a link, or the tunnel head-end and tail-end are
   going to have to fragment and re-assemble packets.  This applies
   recursively.
2) For a number of well-known reasons, it is not desirable to do IP
   packet fragmentation inside the network (it is suboptimal to do
   it anywhere, but inside the network is worse than anywhere else).

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Vishwas Manral
--> Sent: Sunday, November 20, 2005 11:30 PM
--> To: Syed Obaid Amin; [email-masked]
--> Subject: RE: PMTU dicovery
--> 
--> Hi,
--> 
--> A few more minor things to add: -
--> 
--> 1. If the packet is to be sent over the tunnel and needs to 
--> be fragmented we could send the Type=2, Code=0 to the source.
--> 2. One of the documents I found was 
--> http://www.ietf.org/internet-drafts/draft-savola-mtufrag-net
--> work-tunneling-05.txt . You could look at it.
--> 
--> Thanks,
--> Vishwas
--> ________________________________________
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Vishwas Manral
--> Sent: Monday, November 21, 2005 9:32 AM
--> To: Syed Obaid Amin; [email-masked]
--> Subject: RE: PMTU dicovery
--> 
--> Hi Obaid,
--> 
--> I think we do not require sending the PATH MTU to the 
--> original source at all. The original source when doing a 
--> Path MTU would use the tunnel and the PMTU would correctly 
--> work (the tunnel would be another link in the path).
--> 
--> Thanks,
--> Vishwas
--> ________________________________________
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Syed Obaid Amin
--> Sent: Sunday, November 20, 2005 4:38 PM
--> To: [email-masked]
--> Subject: PMTU dicovery
--> 
--> Hi
-->  
--> Can intermediate routers do Path MTU discovery or  the 
--> originator of packet will do it ONLY?
--> for e.g. In case of VPN; can router for encapsulation do 
--> PMTU and send the "PMTU - (size of Data used for 
--> encaspulation)" to Source so encapsulation wont fragment the packet?
-->  
--> Thanks
-->  
--> Obaid Amin
--> 
--> 
--> --------------------------------------------------------------------
--> IETF IPv6 working group mailing list
--> [email-masked]
--> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--> --------------------------------------------------------------------
-->