ietf
[Top] [All Lists]

Re: IPv6 MTU issues in FTTH applications

2002-02-22 13:00:03
On Fri, 22 Feb 2002 09:51:57 EST, fm-listproc(_at_)ns(_dot_)fmmo(_dot_)ca  said:

I am also listing the various approaches to transmit an FTTH IPv6
packet (e.g. H.263 video + G.726 audio over RTP, over UDP, over IPv4
over IPSecV6 over IPv6 with multiple source routing headers {up to 23 ipv6
addresses} and authentication), over multiple Ethernet frames without
using IPv6 packet fragmentation mechanisms.

Ouch.  My head hurts.  What MTU would you need to make this work? ;)

Would it be possible for example to develop a new protocol number at the
Ethernet layer which would identify that two Ethernet frames that are back
to back, originating from the same MAC address, are to be considered glued
together across local links, by the destination IPv6 stack?

Hmm.. There's probably security implications of using this to "tack
onto" an ethernet frame by just dropping a frame with a spoofed MAC
address - since the "second" frame would (presumably) not have an IP
or TCP header, you could use this to inject into an existing connection
without even having to know what the port or TCP sequence numbers were.
Even IPSec doesn't help here, since this can still be used as a denial
of service to arbitrarily disrupt a connection.

How many people are actually using the existing jumbogram support on
gigaE networks? As far as I can tell, a lot aren't, because you still
end up having to do PMTU-D when leaving your local subnet, and we know
how incredibly well THAT works out in the field (my favorite breakages
are sites that filter all ICMP, and access providers that number their
point-to-points out of RFC1918 space so their 'Frag Needed' packets
get tossed by our border router's martian filters)....

-- 
                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech

Attachment: pgpCQ4AaFRxrn.pgp
Description: PGP signature