RE: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Mark,

Thanks for the follow-up; see responses inline below: 

> -----Original Message-----
> From: Mark Smith 
> [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] 
> Sent: Monday, August 22, 2005 6:20 PM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org
> Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"
> 
> Hi Fred,
> 
> On Mon, 22 Aug 2005 09:19:00 -0700
> "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
> 
> > Mark,
> > 
> > Another implementation option which wasn't mentioned is to
> > designate a tunnel pseudo-interface that acts as a "lid" on
> > the can-of-worms consisting of all active tunnels configured
> > on the endpoint. The lid would present a consistent MTU
> > (e.g., 9180 bytes) to upper layers, e.g., for setting the
> > TCP MSS, but there may be instances of locally-generated
> > ICMPv6 "packet too big" messages coming from tunnels inside
> > the can.
> 
> I might get you to clarify this a bit further, so I'm sure I'm
> commenting in the right context. Here is what I understand you're
> describing :
> 
> (1) (Probably) Single "parent" tunnel interface on the 
> tunnel-end-point
> host
> 
> (2) the parent tunnel interface would be used by the host as the
> TCP end point, with the MSS value derived from the interface MTU.
> Normally, the source IPv6 address of the TCP end point would 
> be one of the
> addresses assigned to this parent tunnel interface.
> 
> (3) child tunnels are used to manage actual IPv4 tunnel MTUs, and
> performs fragmentation of the large, assuming the other end also sets
> MSS to be around 9000 bytes, IPv6 segments into IPv4 path MTU 
> sized IPv4
> packets.

Yes to all of the above.
 
> (4) child tunnels would have to all be from and to the same tunnel
> end-point, similar to how ATM virtual channels are all part 
> of the same
> virtual path. I think this would be a requirement because the IPv6
> addressing used for the TCP connections would be derived from 
> the parent
> pseudo-tunnel interface.
> 
> (5) as a consequence of (4), multiple pseudo tunnel interfaces would
> have to exist for different sets of tunnel end points.

Not necessarily on points (4) and (5); I was thinking of having
all of the "worms" in a single "can".
 
> Alternatively, I could see how the pseudo tunnel interface 
> could be used
> to as the IPv6 MTU / MSS value, yet the source IPv6 address 
> used for TCP
> connections is the IPv6 address assigned to the child tunnel 
> being used.
> However, I'd think that would mean modifications to how IPv6 would, by
> default, pick IPv6 source addresses, as I'd think it would usually
> select an address from the outgoing interface that the route table has
> indicated is to be used.

I was thinking multiple IPv6 addresses per node and the addresses
serving more as application endpoint identifiers rather than
node identifiers. I haven't looked to see how well this view
is supported under existing OS's.
 
> If my understanding is correct, then I'd think this parent,
> psuedo-tunnel interface method could suffer from the "fragmentation
> considered harmful" issue, i.e., at the IPv6 TCP connection level, the
> unit of transmission isn't the unit of control.

Independent of whether the pseudo-interface method is used, route
changes can certainly occur after a tunnel's IPv4 segment size has
been determined which could result in ICMPv4 "fragmentation needed"
messages that indicate the loss of a segment smaller than the
TCP unit of transmission. The originating tunnel endpoint can
then either re-segment and retransmit the IPv6 packet or return
an ICMPv6 "packet too big" message back to the original source.
But, that would entail caching original IPv6 packets at the
encapsulator for up to the tunnel's RTT which could be
difficult for large bandwidth*delay tunnels.

Another alternative is for the encapsulator to probe the IPv4
segment size periodically in a proactive "black hole detection"
sort of posture. The frequency for probing could be based on
the arrival of ICMPv4s, which may/may not be accurate (see below).  
 
> I could be completely confused though :-)
> 
> > Again, this seems outside the scope of the
> > specification - do you concur?
> >
> 
> I'd agree that how the tunnels are representated within the 
> OS is mostly
> an implementation detail, although I have had an experience with an
> IPsec implementation that didn't represent tunnels as virtual
> interfaces, which caused a number of issues (routing protocol
> association with the tunnel, applying traffic filtering to traffic
> before it entered the tunnel - a lot of functions on a router are
> commonly oriented towards applying the functions to an specified
> interface). To get around this problem, the vendor 
> recommended solution
> was to create GRE tunnels and then use IPsec transport mode to the GRE
> traffic, which is a bit of a kludge. It probably would have 
> been better
> to have at least a recommendation in the IPsec RFCs as to how to
> represent the IPsec tunnels within an implementation, similar 
> to the way
> the IPv6 neighbour discovery RFC describes a conceptual host
> representation.
> 
> My original thoughts were that the default, initial tunnel MTU was a
> protocol constant, making it in the scope of the RFC, and that setting
> it initially to 1280 bytes would mean that all 
> implementations would use
> 1280 bytes as the default value. Unfortunately it ends up creating a
> constraint on the maximum PMTU value possible, at least when 
> the TCP end
> point is on the same node as the tunnel end-point. 
> 
> Your suggestion in the text to set it higher overcomes that 
> limitation,
> I was making the suggestion to set it higher to try to 
> optimise for the
> common case without requiring any further tunnel configuration.
> 
> Commenting on this from your earlier email :
> 
> > > Alternatively, the tunnel could optimistically set a larger MTU
> > > and return locally-generated ICMPv6 "packet too big" messages
> > > in case it gets ICMPv4 "fragmentation needed" messages back
> > > from the network. But, this method is susceptible to path
> > > MTU-related black-holes when the network fails to deliver
> > > accurate ICMPv4s.
> 
> When you say "accurate", are you refering to routers sending incorrect
> link MTU values when they issue an ICMPv4 Fragmentation 
> Required message
> ? If you are, I personally haven't come across that problem, at least
> that I'm aware of. Is it common ? The only common problem I'm aware of
> in this area is misconfigured firewalls blocking incoming these ICMP
> Fragmentation Required messages, which breaks PMTUD.

Consider an adversary that can wiretap a path and examine tunneled
segments as they fly by. There is nothing to stop such adversaries
from sending gratuitous ICMPv4 "fragmentation needed" messages with
wrong link MTU values back to the originating tunnel endpoint, i.e.,
even though the tunneled segments are actually making it through to
the other side. I personally know of no real-life examples of such
adversaries, but it is easy to postulate their existence.

Fred
fred.l.templin@boeing.com