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

[Tom Herbert <[e-mail]>]

On Sat, Sep 15, 2018 at 6:20 PM, Mark Smith <[e-mail]> wrote:
> On Sun, 16 Sep 2018 at 08:59, Xiejingrong <[e-mail]> 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. "
>
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

>
> 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
>> Subject:Re: New Version Notification for draft-herbert-ipv6-update-opts-00.txt
>>
>> On Fri, Sep 14, 2018 at 6:52 PM, Xiejingrong <[e-mail]> wrote:
>> > 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,
>>
>> 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
>>
>> > Jingrong
>> >
>> > -----Original Message-----
>> > From: Tom Herbert [mailto:[e-mail]]
>> > Sent: Saturday, September 15, 2018 9:12 AM
>> > To: Xiejingrong <[e-mail]>
>> > Cc: 6man <[e-mail]>
>> > Subject: Re: New Version Notification for draft-herbert-ipv6-update-opts-00.txt
>> >
>> > On Fri, Sep 14, 2018 at 6:08 PM, Xiejingrong <[e-mail]> wrote:
>> >> 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 ?
>> >
>> > 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
>> >
>> >
>> >>
>> >> Thanks,
>> >> Jingrong
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: ipv6 [mailto:[e-mail]] On Behalf Of Tom Herbert
>> >> Sent: Saturday, September 15, 2018 7:49 AM
>> >> To: 6man <[e-mail]>
>> >> 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:  <[e-mail]>
>> >> Date: Fri, Sep 14, 2018 at 4:43 PM
>> >> Subject: New Version Notification for
>> >> draft-herbert-ipv6-update-opts-00.txt
>> >> To: Tom Herbert <[e-mail]>
>> >>
>> >>
>> >>
>> >> 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
>> >>
>> >> --------------------------------------------------------------------
>> >> 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
>> --------------------------------------------------------------------