[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

I agree with certain elements of what both Dave and Itojun are
saying. I believe that RFC 2460, section 5 (as quoted by Dave)
provides sufficient administrative assurance that an IPv6-in-IPv4
tunnel decapsulator can reassemble packets up to 1500 octets. The
only problem with Dave' s proposal is that, with no prior negotiation,
the encapsulator has no way of knowing whether its tunneled packets
will be fragmented by the IPv4 network, which could lead to black
holes and/or poor performance. Reasons:

 1) certain middleboxes drop IPv4 fragments; sometimes
    sending only the first fragment on to the final destination

 2) Fragmenting IPv4 packets causes slow-path processing in
    some middleboxes

 3) some middleboxes may not implement IPv4 fragmentation
    at all

Itojun seems to be suggesting that an initial negotiation is needed to
determine the MRU, and while learning the true MRU would clearly
be a good thing it seems to me that the 1500 byte minimum MRU
indicated by Dave is a reasonable assumption, and the true MRU
will most likely be discovered in the TCP MSS negotiation anyway.

However, I see a clear and necessary purpose for an initial negotiation,
which is to determine a lower bound on the minimum IPv4 link MTU
for the links on the IPv4 path from the encapsulator to the decapsulator.
Discovering the minimum IPv4 link MTU is necessary to determine the
maximum IPv6 packet/fragment size that can traverse the tunnel without
incurring IPv4 fragmentation.

So, I believe the initial negotiation is necessary and the best mechanism
to support this is sending an IPv6 Router Solicitation and getting an IPv6
Router Advertisement back. (My writings have talked about using RS/RA
exhanges for MTU negotiations among other purposes for a long time now.)
Reasons why using the RS/RA mechanism is best:

 1. We can pad the RSs to a particular size (e.g., 512 bytes, 1280 bytes,
   etc.) to "plumb" the IPv4 path MTU and get an initial lower bound
   on the minimum IPv4 link MTU.

 2. We can verify that any RAs received come from a trusted router
   using, e.g., SEND or some other trust mechanism so that we will
   not be vulnerable to learning bad MTU/MRU information from
   malicious nodes.

I talk about this particular approach in my current document on
Dynamic MTU determination for IPv6-in-IPv4 tunnels found at:

http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-04.txt

but the approach can be augmented by including the decapsulator's
MRU in the RA messages it returns. This might require adding a
new type of MRU option, such as the ones I have discussed in
some of my past works.

Fred
ftemplin@iprg.nokia.com



Jun-ichiro itojun Hagino wrote:

The current text is ambiguous as to whether it would be legal or
illegal for the mobile node to (say) use a larger MTU on interface 2 (with IPv4 DF bit clear) automatically upon being configured to be a mobile node. Is the intent that this is illegal? If so, this seems harmful, and it would be good to point out that excessive fragmentation will occur for mobile nodes. If this is not the intent, then the language should be clarified.

Also on the sentence:


A larger fixed MTU should not be configured unless it has
been administratively ensured that the decapsulator can reassemble
packets of that size.


RFC 2460 section 5 says:


A node must be able to accept a fragmented packet that, after
reassembly, is as large as 1500 octets.


Is this statement sufficient "administrative assurance" that the decapsulator can reassemble packets up to 1500 octets in size?

If so, I'd propose rewording as:


A fixed MTU larger than 1500 bytes should not be configured unless it


has


been administratively ensured that the decapsulator can reassemble
packets of that size.



	the above sentence encourages unmatched/unnegotiated MTU/MRU
	configuration.  i saw problems with these in the past so i'm skeptical
	with the suggested change.

itojun