In message <[email protected]>, "C. M. Heard " writes: > On Mon, 19 Aug 2013, C. M. Heard wrote: > > On Tue, 6 Aug 2013, Mark Andrews wrote: > > > http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt > ... > > In answer to to the open questions, I would suggest using a single > > option code and making the protocol explicit. The strategy of > > leaving the protcol implicit leads to ambigiuities (e.g., between > > TCP, UDP, and UDP-lite). I would also suggest judicious use of > > padding to align 4 and 8 bytes quantities on natural boundaries. > > It occurs to me that instead of having a different option format for > every single upper-layer protocol, one could instead just package > the portion of the header chain (extension headers, if any, and > upper-layer header) that appears after the fragmentation header in > the initial fragment. That would require only a single option code, > would apply to all present and future upper-layer protocols, and > would provide the requisite upper-layer information in a form that > those who want it must already know how to parse. The option would > look like this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|1| (TBD) | Opt Data Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Portion of header chain following offset=0 fragment header + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The type would be chosen to indicate that the option is mutable and > is to be skipped if it is not recognized. The alignment requirement > would be 8n+6, since the upper-layer header and any preceding > extension headers always are aligned on 8-octet boundaries. > > Here are some other suggestions: > > - Make this a destination option that appears before the > fragmentation header, not a hop-by-hop option, as discussed in a > previous e-mail in this thread.
It is quite possible to develop asics which understand this option the same way as there are asics which process tcp and udp headers. > - This option MUST NOT appear in an initial fragment (or in an > unfragmented fatagram). That avoids the possibiity that a > middlebox will interpret a datagram differently from an end system > (or another middlebox). This is a non starter. Whatever change we make needs to be visible in all fragment. Firewalls need to be able to identify if the packet is following old fragmentation rules or new fragmentation rules so it can decide if it is applying old policy or new policy. > - New end-system implementations MUST have the capability to insert > this option in non-initial fragments. That capability MUST be > configurable, and the default SHOULD be to insert the option. > > - If a forwarding node discards a packet containing this option, it > MUST be the result of a configurable policy, and not just the > result of a failure to recognize the option. By default, the > policy SHOULD be the same that the node would apply to an initial > fragment with the same header chain that is in the option, and > that in turn SHOULD be the same policy that the node would apply > to an unfragmented datagram with the same header chain (less the > fragmentation header). > > - A forwarding node that rewrites the flow label MAY use the > information available in this option for that purpose. > > - An end system is not required to process this option. However, if > it does, it SHOULD ensure that the copies the upper-layer in the > various fragments match what appears in the initial fragment, and > that the option does not appear in an initial fragment (or in an > unfragmented datagram). [Define codes and pointers for an ICMPv6 > Parameter Problem message that indicates these situations.] > > Acknowledgments to draft-ietf-6man-ext-transmit-03 for some stolen > text. > > Item for discussion: does it really matter whether or not this > option is marked as mutable? It would not be covered by an > Authetication Header in any case since "AH is applied only to whole > IP datagrams (not to IP fragments)" [RFC 2402] and this option is > inserted only after fragmentation. A NAT does not respect > immutability (as defined in RFC 2402), so the possibility of a NAT > being on the path does not seem like a good reason to mark it > mutable. On the other hand, what benefit could there be from > marking it as immutable? > > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
