On Jun 24, 2013, at 15:11 , Ronald Bonica <rbon...@juniper.net> wrote:
>> 
>> "Network operators MAY filter IPv6 fragments."
> 
> Ack. It is a statement of fact, not an IETF imposed requirement.

I hate to be *that* guy... but, perhaps you want to bin this whole draft if you 
don't want to impose that requirement.

>>  Updates: RFC 2460
>>  Intended status: Standards Track 
>>  [...]
>>  Requirements Language
>> 
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                                             ^^^^^
>>    document are to be interpreted as described in RFC 2119 [RFC2119].

>> 5. MAY  This word, or the adjective "OPTIONAL", mean that an item is
>>    truly optional.  One vendor may choose to include the item because a
>>    particular marketplace requires it or because the vendor feels that
>>    it enhances the product while another vendor may omit the same item.
>>    An implementation which does not include a particular option MUST be
                                                                   ^^^^
>>    prepared to interoperate with another implementation which does
>>    include the option, though perhaps with reduced functionality. In the
>>    same vein an implementation which does include a particular option
>>    MUST be prepared to interoperate with another implementation which
>>    does not include the option (except, of course, for the feature the
>>    option provides.)

This draft, if published with the precise wording I quoted above, would be IETF 
establishing a new requirement for IPv6 hosts to "be prepared to interoperate 
with" [network operators] that implement the option of dropping IPv6 fragments.

It's one thing for $ENTERPRISE to tell us that their network won't forward our 
IPv6 fragments.  In theory, that can be worked out under a bilateral agreement. 
 It's another thing entirely for IETF to tell everyone that our host 
implementations MUST be prepared to operate in networks that refuse to forward 
IPv6 fragments.  I have to assume that IPv6 Ready certification tests would be 
updated to validate conformance to this updated standard.

Please don't let anyone be confused about what is entailed for conformance to 
this update of RFC 2460.  This is quite a major change to the Internet Protocol 
Version 6.  I'm inclined to agree with other who say this proposal is so 
radical that it should warrant incrementing the major version number.


--
james woodyatt <j...@apple.com>
core os networking

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to