Subject: RE: Modifiable Destination Options

From: Xiejingrong <[email-masked]>
Date: Sat, 8 Sep 2018 06:54:31 +0000

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.

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:[email-masked]] On Behalf Of Fred Baker
Sent: Saturday, June 30, 2018 5:38 AM
To: Tom Herbert <[email-masked]>
Cc: IPv6 IPv6 List <[email-masked]>; 神明達哉 <[email-masked]>
Subject: Re: Modifiable Destination Options

> On Jun 29, 2018, at 9:54 AM, 神明達哉 <[email-masked]> wrote:
> 
> At Thu, 28 Jun 2018 15:09:05 -0700,
> Tom Herbert <[email-masked]> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 14 Sep 2018 10:23:06 -0700

> (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

---

From: Xiejingrong <[email-masked]>
Date: Sat, 15 Sep 2018 02:57:27 +0000

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.

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:[email-masked]] 
Sent: Saturday, September 15, 2018 1:23 AM
To: Xiejingrong <[email-masked]>
Cc: Fred Baker <[email-masked]>; IPv6 IPv6 List <[email-masked]>; 神明達哉 <[email-masked]>
Subject: Re: Modifiable Destination Options

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

>>> 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?
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Sep 2018 15:31:42 +1200

>    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

---

From: Xiejingrong <[email-masked]>
Date: Sat, 15 Sep 2018 03:58:17 +0000

OK. The HBH is ignored by default. So you seems not opposed to the word of "deprecated" ;-)

Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Saturday, September 15, 2018 11:32 AM
To: [email-masked]
Subject: Re: Modifiable Destination Options

>    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

> Cc: Fred Baker <[email-masked]>; IPv6 IPv6 List 
> <[email-masked]>; 神明達哉 <[email-masked]>
>>> IETF IPv6 working group mailing list [email-masked] Administrative 
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Sep 2018 16:25:28 +1200

> OK. The HBH is ignored by default. So you seems not opposed to the word of "deprecated" ;-)

Well, we simply stated that it may not work as expected! That is not as strong
as deprecation. I think the ITU is more fond of formal deprecation than the IETF.

     Brian

---

From: Tom Herbert <[email-masked]>
Date: Sat, 15 Sep 2018 08:58:34 -0700

> 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