Subject: RE: (ngtrans) Re: 6to4/isatap MTU

From: "Christian Huitema" <[email-masked]>
Date: Tue, 3 Sep 2002 17:19:59 -0700

> From: Fred L. Templin [mailto:[email-masked]]
> 
> Jun-ichiro itojun Hagino wrote:
> >>Christian's proposal above gives a nice proposal for a set of
> decapsulator
> >>actions. There are also some details to discuss regarding the
> encapsulator:
> >
> > 	i don't think it a good strategy for encapsulator/decapsulator
to
> > 	keep state (incl. PMTU info) on their peers.  here's much more
> > 	simple one:
> 
> Disagree - there is no more state involved than for standard IPv6
neighbor
> discovery, i.e., the IPv6 destination cache is used. This is soft
state
> that
> does not suffer from catastrophic loss due to failure and can be
bounded
> to
> an amount that is acceptable for the encapsulator's H/W architecture.
No
> IPv4 PMTU state is needed at all, as per your "fundamental design
> requirements" from 8/18/2002.

To clarify, I did not intent the "encapsulator" to keep any state, not
any more that I would intend an intermediate router to keep any state.
The ICMPv6 "packet too big" goes to the origin of the IPv6 packet, in
exactly the same way that any ICMPv6 originated by an intermediate IPv6
router. This sending node performs straightforward IPv6 PMTU discovery.

> > 	IPv6 tunnel link MTU: 1280
> > 	IPv6 tunnel link MRU: 1480 (minimum required supported value)
> > 	for configured tunnels, peers can pre-negotiate for larger
> (constant)
> > 	value.
> 
> Why would you place such an artificial limit on automatic tunnel
> interfaces
> that may benefit from larger values? (See my comments on the state
issue
> above...)

I see Itojun's point: tunnels are a transition strategy; we don't want
to plug too much complexity in any transition strategy; it is OK to keep
it simple even if it causes degraded performance, because simplicity
reduces support cost, and tunneling causes performance issue anyhow.

-- Christian Huitema

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 06:40:07 -0700

Christian,

> reduces support cost, and tunneling causes performance issue anyhow.

I find this astonishing. You have clearly been doing alot of thinking
about the "decapsulator monitors IPv4 fragmentation" solution dating
back to your message on 8/21/2002. You have proposed a well thought-out
decapsulator algorithm in your message dated 9/02/2002. Now you just throw
your hands up and say: "Let's forget the whole thing and go with the
lowest common denominator solution"? Please explain...

Fred
[email-masked]