Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-opts-00.txt

From: Tom Herbert <[email-masked]>
Date: Fri, 14 Sep 2018 16:49:02 -0700

Hello,

I submitted a new version of draft to update option requirements.
Since this now includes updates to requirements that cover both
DestOpts and HBH options, I renamed the draft. Other changes include
feedback from the list. I also added a section on detecting that
Destination Options precede a Routing header which is needed if they
are to be processed differently.

Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Sep 14, 2018 at 4:43 PM
Subject: New Version Notification for draft-herbert-ipv6-update-opts-00.txt
To: Tom Herbert <[email-masked]>

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

Name:           draft-herbert-ipv6-update-opts
Revision:       00
Title:          Updates to Requirements for IPv6 Options
Document date:  2018-09-14
Group:          Individual Submission
Pages:          6
URL:
https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-opts-00.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-ipv6-update-opts/
Htmlized:       https://tools.ietf.org/html/draft-herbert-ipv6-update-opts-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-opts

Abstract:
   This document updates requirements for IPv6 Destination and Hop-by-
   Hop Options. The requirements that option type and option length
   cannot change en route, as well as the requirements that options
   cannot be added or removed, are made explicit. The meaning and
   requirements of a Destination Option marked as changeable are
   clarified. Finally, the requirement that all destinations listed in a
   Routing header must process options in a Destination Options header
   preceding the Routing header is relaxed.

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

---

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

Hi Tom,

I have read the fresh draft just now.
I agree with you some of the good catch, "Intermediate destination nodes may be closer in taxonomy to switches and routers than end hosts".
But I did not agree with this point, "Allowing nodes to ignore options retains the primary value and usability of Destination Options preceding a Routing header."
Quite the contrary, I do think the "Destination Options preceding a Routing header" should not happen absolutely."
Because, once you put a DestOptHdr preceding a RH, then the DestOptHdr can't be removed, but the RH can be popped by an router. How will that happen ?

Thanks,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Saturday, September 15, 2018 7:49 AM
To: 6man <[email-masked]>
Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-opts-00.txt

Hello,

I submitted a new version of draft to update option requirements.
Since this now includes updates to requirements that cover both DestOpts and HBH options, I renamed the draft. Other changes include feedback from the list. I also added a section on detecting that Destination Options precede a Routing header which is needed if they are to be processed differently.

Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Sep 14, 2018 at 4:43 PM
Subject: New Version Notification for draft-herbert-ipv6-update-opts-00.txt
To: Tom Herbert <[email-masked]>

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

Abstract:

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
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 14 Sep 2018 18:12:19 -0700

> Because, once you put a DestOptHdr preceding a RH, then the DestOptHdr can't be removed, but the RH can be popped by an router. How will that happen ?

Xiejingrong,

The routing header can't be removed either. Per RFC8200:

"Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet's delivery
path, until the packet reaches the node (or each of the set of nodes,
in the case of multicast) identified in the Destination Address field
of the IPv6 header."

Tom

---

From: Xiejingrong <[email-masked]>
Date: Sat, 15 Sep 2018 01:52:20 +0000

Hi Tom,

Suppose a network with these router nodes: CE1--PE1--P1-P2-P3-PE2--CE2.
PE1 impose an outer IPv6 Header on the customer IP packet, with a DestOptHdr preceding a RoutingHdr, with the final Dest PE2, and the intermediate dest P2.
P2 will have to keep the DestOptHdr because the DestOptHdr is preceding a RoutingHdr.
PE2 will also keep the DestOptHdr first because the DestOptHdr is preceding a RouthingHdr, and PE2 can't judge if it is the final dest until it check the following RH in a detailed way, and I suppose it will not do.
Then PE2 goto the RH, and pop the RH according to the handling of RH itself.
What is the time to remove the DestOptHdr that PE1 imposed ? 
One may think that, after when RH is removed then the DestOptHdr should also removed, but that will bring the handling of DestOptHdr to the handling of RH.

Jingrong

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Saturday, September 15, 2018 9:12 AM
To: Xiejingrong <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: New Version Notification for draft-herbert-ipv6-update-opts-00.txt

Xiejingrong,

"Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 15 Sep 2018 09:04:04 -0700

> One may think that, after when RH is removed then the DestOptHdr should also removed, but that will bring the handling of DestOptHdr to the handling of RH.
Jingrong,

If I understand your example correctly, PE1 is encapsulating packets
from CE1 in IPv6 packets that have both a Routing header and
Destination Options (or maybe even other extension headers). PE2 is
the final destination of the encapsulating packet, so the IP in IP
encapsulation is terminated there and the encapsulated packet
continues on the CE2. "Popping the RH" really means terminating the IP
encapsulation which means everything about the outer packet
encapsulation created by PE1 is discarded (all headers from the outer
IP header to the inner one.). So this isn't removing extension
headers, it's just processing received a packet at its final
destination (i.e. the tunnel end point in encapsulation).

Tom

---

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

Yes it is the case of a ipv6 tunnel end point, and the final dest. But the final dest is a router instead of a host OS. IPv6 node is classified as host or router and have different requirements. I belive host node can do the final dest things as you described in the draft. But a tunnel endpoint router can not do the final dest things right as you described in the 3 opinions to judge the final dest for a DestOptHdr preceding a RH.

Jingrong
From:Tom Herbert
To:Xiejingrong,
Cc:6man,
Date:2018-09-16 00:04:22
Subject:Re: New Version Notification for draft-herbert-ipv6-update-opts-00.txt

Jingrong,

Tom

---

From: Mark Smith <[email-masked]>
Date: Sun, 16 Sep 2018 11:20:24 +1000

On Sun, 16 Sep 2018 at 08:59, Xiejingrong <[email-masked]> wrote:
>
> Yes it is the case of a ipv6 tunnel end point, and the final dest. But the final dest is a router instead of a host OS. IPv6 node is classified as host or router and have different requirements.

So I think you're thinking of a router or a host as a type of device,
rather than as functions.

>From RFC8200,

"   router       a node that forwards IPv6 packets not explicitly
                addressed to itself.

   host         any node that is not a router. "

So when a packet arrives at a device where the Destination Address in
the packet matches one of the device's configured addresses, then
processing is host processing - even if the device looks like a
"router".

As Brian Carpenter observed a few years ago during the work on
RFC7943/BCP204, "Host Address Availability Recommendations",
tunnelling endcap/decap is host processing.

There's a variety of ways you can tell that host processing is
occurring on a packet, regardless of what the device physically looks
like.

- processing of the packet involves more than just the processing
required to forward the packet towards the next hop on its trip

- processing of the packet involves more than just processing the IPv6
packet's header, it involves processing of the packet payload i.e.
transport layer and application layer processing

- the device processing the packet is assigned the address that
appears in the packet's destination address field

- conceptually, processing has changed 90 degrees from horizontal
processing (forwarding "across" the network), to vertical processing
(packet processing "up" the stack at the destination host.)

A router as a device is actually performing routing as a function
(forwarding), and host processing (CLI, OSPF, BGP etc.). OSPF and BGP
processing are host applications, with their application being to
populate the forwarding table used by the routing function. OSPF and
BGP are processing packets that have DAs assigned to the router
device.

A counter example to further demonstrate the point about devices
verses functions. If you go and buy a router from a router device
vendor, and then operate it as a BGP Route Reflector, so that it is
never in-line with forwarded packets, and never for the whole of its
life forwards any packets, is it still a "router"?

Regards,
Mark.

> I belive host node can do the final dest things as you described in the draft. But a tunnel endpoint router can not do the final dest things right as you described in the 3 opinions to judge the final dest for a DestOptHdr preceding a RH.
>
> Jingrong
> From:Tom Herbert
> To:Xiejingrong,
> Cc:6man,
> Date:2018-09-16 00:04:22
> > Suppose a network with these router nodes: CE1--PE1--P1-P2-P3-PE2--CE2..

---

From: Tom Herbert <[email-masked]>
Date: Mon, 17 Sep 2018 09:48:55 -0700

>    host         any node that is not a router. "
Mark,

Agreed that terminating an IP tunnel is a host function. But, this
discussion does raise another philosophical question: What is an
intermediate node in a routing header? It seems like these have some
characteristics of both hosts and routers!

Tom