General comment - it would be nice if folks would reveiw and comment on my drafts: http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt
Ok, the second one first:
As far as I can tell, not being someone who builds routers, some of the mechanisms outlined here are problematic. For instance, determining whether the IP packet that carries a tunneled packet was fragmented means transferring information from one place in the architecture (reception and reassembly of IP packets) to another (handling protocol 41). Another: doing a router sollicitation triggered by wanting to transmit a packet of a certain size is not a good thing.
But why bother in the first place?
Presonally, I would happily let my tunnel packets be fragmented as this way I don't incur a reduced MTU when using a tunnel. Sure, this costs extra CPU time for the tunnel endpoints but in most cases this isn't a problem. And when it is, the tunnel endpoints should be able to do PMTUD over the tunnel. And if that doesn't work, it's always possible to configure a smaller MTU. Don't forget that tunnels are typically pretty static so once everything is set up, there shouldn't be too many surprises.
I think this draft is solving a non-problem.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
