Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

james woodyatt <jhw@apple.com> Mon, 24 June 2013 22:35 UTC

Return-Path: <jhw@apple.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6636821E8129 for <ipv6@ietfa.amsl.com>; Mon, 24 Jun 2013 15:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk+CzOFih9Mu for <ipv6@ietfa.amsl.com>; Mon, 24 Jun 2013 15:35:43 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E212521E811A for <ipv6@ietf.org>; Mon, 24 Jun 2013 15:35:43 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOX00D0O5ERMY61@mail-out.apple.com> for ipv6@ietf.org; Mon, 24 Jun 2013 15:35:42 -0700 (PDT)
X-AuditID: 11807158-b7f486d0000079b6-2d-51c8c9be22c5
Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id C7.8D.31158.EB9C8C15; Mon, 24 Jun 2013 15:35:42 -0700 (PDT)
Received: from ba0301a-dhcp116.apple.com ([17.193.14.244]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOX00KLH5FICD50@marigold.apple.com> for ipv6@ietf.org; Mon, 24 Jun 2013 15:35:42 -0700 (PDT)
Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
From: james woodyatt <jhw@apple.com>
In-reply-to: <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com>
Date: Mon, 24 Jun 2013 15:35:41 -0700
Message-id: <57D2AF30-1FC4-4B5E-8F48-4169384746B3@apple.com>
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1779)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FDcorvv5IlAg+e7FC1enn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKcfNzEW/BSp2HjjL1MD4zv+LkZODgkBE4lju9axQNhiEhfu rWfrYuTiEBKYxCSx7PQVZghnAZNET99ksCpmAS2J9TuPM4HYvAJ6EjOnTWIEsYUFgiV2HJwC FmcTUJH4dvkumM0pkCxxesMJsF4WAVWJ9xMuMUPM0ZZ48u4CK8QcG4nDTTPZIZb9ZJJY1D8R bKiIgLLEjO5zbBDnyUqc6bnJMoGRfxaSO2YhuWMWkrkLGJlXMQoUpeYkVprqJRYU5KTqJefn bmIEB1lhxA7G/8usDjEKcDAq8fB+iDsRKMSaWFZcmXuIUYKDWUmEN1QEKMSbklhZlVqUH19U mpNafIhRmoNFSZxX0ut4oJBAemJJanZqakFqEUyWiYNTqoFxTWDGhF+Zx07tX6MYEKL+rWzd 5SlGLqen+Xnvu5NfIbhz+7/DIWnuf5zizk+8tScnrLUhvnb+6/RifqNfOmd+bC8vKWy92WRT F7viEtfcL2uElHx4rj7MiXq+08lwinn3os6n9/qOFSZPce7mkHiq8KnfP/9OcG5W69+Xp6wk mPcUH9op9F5FiaU4I9FQi7moOBEA8RImLS4CAAA=
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 22:35:50 -0000

On Jun 24, 2013, at 15:11 , Ronald Bonica <rbonica@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 <jhw@apple.com>
core os networking