RE: New Version Notification for draft-herbert-ipv6-update-dest-ops-00.txt

Hi Tom, 

For the below description:
   If a Destination Option is marked to be changeable (the third-highest
   order bit of the option type is set) and is in a Destination Options
   header that follows a Routing header, or there is no Routing header
   present, then the Option Data cannot be changed en route. There are
   no nodes in the path that are permitted to change the Option Data.

I think it did not consider the Destination Option when IPv6 DA being Multicast Address.
Multicast routing is also a kind of routing and one can find many 'multicast routing' RFCs.
And obviously, Destination Option can be used with Multicast Address as IPv6 DA. 

To quote RFC8200:

   The Option Type identifiers are internally encoded such that their
   highest-order 2 bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
Sent: Saturday, August 18, 2018 3:29 AM
To: 6man <ipv6@ietf.org>
Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-dest-ops-00.txt

Hello,

I wrote up a short draft to try to clarify the requirements of processing Destination Options that are before a Routing header. This work was motivated by some of the discussions around SRv6. It also would one of the arguments that TLVs in SRv6 are needed because Destination Options can't be ignored at SRv6 destinations. The draft also clarifies what it means for a Destination Option to be changeable en route.

Thanks,
Tom

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: Fri, Aug 17, 2018 at 12:18 PM
Subject: New Version Notification for draft-herbert-ipv6-update-dest-ops-00.txt
To: Tom Herbert <tom@quantonium.net>

A new version of I-D, draft-herbert-ipv6-update-dest-ops-00.txt
has been successfully submitted by Tom Herbert and posted to the IETF repository.

Name:           draft-herbert-ipv6-update-dest-ops
Revision:       00
Title:          Updates to Destination Options Processing
Document date:  2018-08-17
Group:          Individual Submission
Pages:          5
URL:
https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-dest-ops-00.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-ipv6-update-dest-ops/
Htmlized:
https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-dest-ops

Abstract:
   This document updates the requirements for processing Destination
   Options in IPv6 in two ways. First, the requirement that all
   intermediate destinations in a Routing header must process options in
   a Destination header appearing before the Routing header is relaxed.
   Secondly, the processing of a Destination Option marked as changeable
   is clarified.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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