[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
(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.
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.
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.
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.
Thanks,
Mark.