RE: [RAM] Tunneling overheads and fragmentation

Robin,

This may not address all of your questions, but here is
something that may help with IPv6-in-IPv4 tunnel MTUs:

  http://www.ietf.org/internet-drafts/draft-templin-linkadapt-06.txt

See also RFCs 4459 and 4821.

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Robin Whittle [mailto:rw@firstpr.com.au] 
> Sent: Thursday, July 19, 2007 7:34 AM
> To: ram@iab.org
> Subject: [RAM] Tunneling overheads and fragmentation
> 
> Can anyone help me understand the likely problems with tunneling
> packets and what MTU limits might be exceeded if LISP, eFIT-APT or
> Ivip is used with IPv4?
> 
> I understand that fragmentation in IPv4 is very much to be
> avoided.  I understand that in IPv6, each host is supposed to
> explore how long it can make the packets without getting error
> messages from some router en-route whose length limit is exceeded.
> 
> 
> eFIT-APT tunnel endpoints are always within provider networks.
> With LISP the ETRs and ITRs are also probably in provider
> networks.  With Ivip, ITRs could be in the end-user network,
> including an ITFH function in the sending host.
> 
> What sort of limits are there likely to be with the maximum length
> of IP packets on any of these routes.
> 
> For instance, if all provider and transit routers happily handle
> packets significantly longer than whatever hosts normally produce
> (say 1500 bytes) then adding the encapsulation won't lead to any
> fragmentation.  Is this a reasonable assumption?
> 
> What about routers in end-user networks, or CE routers of providers?
> 
> I could imagine some trouble if the main TCP/IP stack of a host
> produced a packet which was at the maximum length which could be
> handled by its DSL modem (and the NAT function of that
> modem/router) but that if an additional item of software in the
> host added an Ivip header to it, then there would be problems.
> 
> Likewise if the NAT function in the host had an ITFH function
> which caused packets to get longer before they actually traversed
> the "modem" link and went to whatever router was at the other end
> of it, which might have an MTU limit which then gets exceeded.
> Perhaps a NAT device with such a function would send out different
> DHCP responses with smaller MTU and MSS so the hosts would
> generally be making packets which were suitable for being
> encapsulated.
> 
> In Mobile IP, how do mobile nodes handle the extra length of the
> packets they tunnel to their home agent?  Does the additional
> mobile IP software in the host operating system somehow change the
> MTU and MSS of the layer above it which is preparing packets, not
> knowing they are to be further encapsulated?
> 
> 
>  - Robin
> 
> 
> _______________________________________________
> RAM mailing list
> RAM@iab.org
> https://www1.ietf.org/mailman/listinfo/ram
> 

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram