option 212 for 6RD
Lorenzo Colitti
lorenzo at google.com
Fri Jan 18 05:18:42 CET 2013
On Fri, Jan 18, 2013 at 2:08 AM, Sam Wilson <Sam.Wilson at ed.ac.uk> wrote:
> In principle PMTUD is the more technically elegant way - finding out
> what's out there and adapting to it. Mandating a fixed MTU is actually not
> simple since I guess you'd have to allow for tunnelling, extension headers
> and so on that might be added along the path and which would rob space from
> the data field. You'd have to require a physical MTU larger than the
> logical MTU with enough headroom to allow for extra overhead, and *still*
> have a method of dealing with any overflows en route caused by, say,
> multiple layers of tunnelling.
>
> It all gets a bit awkward.
Agreed. Reality is often messy.
My personal opinion is that we should rely on path MTU to work but, due to
the latency impact, try not to rely on it too often (and so, for example,
lower the RA MTU on networks that *know* they are behind a tunnel).
I don't know how many people agree with me though. And I also don't know if
we can depend on PMTUD to work if we don't rely on it often.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130118/1464b02c/attachment.htm>
More information about the ipv6-ops
mailing list