Re: Modifiable Destination Options

[Tom Herbert <[e-mail]>]

On Fri, Sep 14, 2018 at 8:58 PM, Xiejingrong <[e-mail]> wrote:
>
> OK. The HBH is ignored by default. So you seems not opposed to the word of "deprecated" ;-)
>
Jingrong,

Deprecation is not the intent. The change was an acknowledgement that
many implementations do not conform, and will likely never conform, to
the requirements. Relaxing the requirements in this way best preserves
the utility of HBH, as opposed to other ad hoc behaviors of network
devices that render them completely useless such as arbitrarily
dropping packets with HBH.

Tom

> Jingrong
>
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Saturday, September 15, 2018 11:32 AM
> To: [e-mail]
> Subject: Re: Modifiable Destination Options
>
> On 2018-09-15 14:57, Xiejingrong wrote:
>> Hi Tom,
>>
>> I guess the HBH had been deprecated after the RFC8200 required the default behavior to discard the HBH. Per the RFC8200:
>>
>>    NOTE: While [RFC2460] required that all nodes must examine and
>>    process the Hop-by-Hop Options header, it is now expected that nodes
>>    along a packet's delivery path only examine and process the
>>    Hop-by-Hop Options header if explicitly configured to do so.
>
> There is no mention of *discard* there. The forwarding node simply ignores the HBH header.
>
>     Brian
>
>>
>> Again, the BIER is not a hop-by-hop behavior, because it must support to run over some form of tunnels like SRH.
>>
>> Also from the security side, from the flexibility side, any IPv6 Options is defined in some preceding 'Context' is much better in my opinion.
>>
>> For BIER, such a 'Context' is the Multicast DA which defined by some control-plane or manage-plane to indicating to check What EH (DestOptHdr) and what TLVs in the EH(the-only-BIER-TLV).
>>
>> For SRH, such a 'Context' is the Unicast DA which defined by some control-plane or manage-plane to indicating to check what TLV to support and how to deal with such TLV.
>>
>> All such 'Context' is a local behavior, just like how the RFC8200 changed for the handling of HBH: "if explicitly configured to do so".
>>
>> Jingrong
>>
>>
>> -----Original Message-----
>> From: Tom Herbert [mailto:[e-mail]]
>> Sent: Saturday, September 15, 2018 1:23 AM
>> To: Xiejingrong <[e-mail]>
>> Cc: Fred Baker <[e-mail]>; IPv6 IPv6 List
>> <[e-mail]>; 神明達哉 <[e-mail]>
>> Subject: Re: Modifiable Destination Options
>>
>> On Fri, Sep 7, 2018 at 11:54 PM, Xiejingrong <[e-mail]> wrote:
>>> Hi all,
>>>
>>> I think the Destination Options is different from HBH, though they share "The same Option Type numbering space", and have the same "Modifiable or not" bit.
>>>
>>> The draft <draft-xie-6man-bier-encapsulation> means to use such a "Modifiable Destination Options" with a Multicast Address in the IPv6 DA.
>>>
>>> My understanding about the "change en route to the packet's final
>>> destination" is that,
>>>
>>> (1) For a Multicast Address in IPv6 DA, the "final destination" is the IPv6 node(s) who don't forward the packet anymore. And thus the "Modifiable Destination Options" is required.
>>>
>>> (2) If is also suitable for cases when Unicast Address in IPv6 DA and Destination Options is ahead of Routing header.
>>>
>>
>> Hi Xiejinggrong,
>>
>> I don't think it should matter whether the final destination is multicast or unicast. The final destination is at the node that is addressed in the destination address. In the case of multicast, it's simply the end nodes that receive the packets as addressed by the multicast address.
>>
>> It is unclear to me if a Destination Option is appropriate for BIER.
>> It seems like the target of the information is intermediate routers in the path that are not explicitly addressed by the destination address (i.e. there's no routing header present that writes destination addresses en route). Should this be a Hop-by-Hop option instead?
>>
>> Tom
>>
>>> To quote two paragraphs of RFC8200:
>>>       note 1: for options to be processed by the first destination that
>>>               appears in the IPv6 Destination Address field plus
>>>               subsequent destinations listed in the Routing header.
>>>
>>>    The third-highest-order bit of the Option Type specifies whether or
>>>    not the Option Data of that option can change en route to the
>>>    packet's final destination.
>>>
>>> Thanks
>>> Jingrong
>>>
>>> -----Original Message-----
>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Fred Baker
>>> Sent: Saturday, June 30, 2018 5:38 AM
>>> To: Tom Herbert <[e-mail]>
>>> Cc: IPv6 IPv6 List <[e-mail]>; 神明達哉 <[e-mail]>
>>> Subject: Re: Modifiable Destination Options
>>>
>>>
>>>
>>>> On Jun 29, 2018, at 9:54 AM, 神明達哉 <[e-mail]> wrote:
>>>>
>>>> At Thu, 28 Jun 2018 15:09:05 -0700,
>>>> Tom Herbert <[e-mail]> wrote:
>>>>
>>>>> I don't see that that setting this bit for a Destination Option is
>>>>> prohibited. So what is the effect of setting a Destination Option
>>>>> type to be modifiable en route?
>>>
>>> I thought the point of a destination option was that it was only evaluated by the system identified by the destination address? If it's being modified in flight, that sounds like it belongs in the HBH header.
>>>
>>>>> Is setting a Destination Option to be changeable en route valid? I
>>>>> suppose the text that extension headers except for HBH can't be
>>>>> processed in transit implies that a DO can never be modified en
>>>>> route and trumps the DO changeable bit, but are there case where it
>>>>> could be legitimately be changed, maybe the end host is allowed to
>>>>> modify the option before delivery to the application?
>>>>
>>>> When used with a routing header?
>>>>
>>>> --
>>>> JINMEI, Tatuya
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list [e-mail] Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------