RE: I-D Action: draft-bonica-6man-ext-hdr-update-01.txt

[Ron Bonica <[e-mail]>]

Hi Brian,

As always, thanks for the thoughtful review. I will post a new version in the next few hours addressing your comments. Until then, responses inline......

                                                                                           Ron


Juniper Business Use Only

-----Original Message-----
From: Brian E Carpenter <[e-mail]> 
Sent: Monday, March 9, 2020 12:18 AM
To: 6man <[e-mail]>; Ron Bonica <[e-mail]>
Subject: Re: I-D Action: draft-bonica-6man-ext-hdr-update-01.txt

Hi,

I'm going to nit-pick the crucial text in the draft, without taking a position on whether it should go forward. I think it's essential to get the text right before we take any sort of decision.

> 2.  Terminology
> 
>    The following terms are used in this document:
> 
>    o  Source node - An IPv6 source node accepts data from an upper-layer
>       protocol, encapsulates it in an IPv6 header, and sends the
>       resulting IPv6 packet to a destination node.

Actually it doesn't encapsulate, it simply prepends the IPv6 header.

[RB] Agree. Fixed in the new version.
 
>    o  Destination node - An IPv6 destination node receives an IPv6
>       packet and delivers its payload to an upper-layer protocol.

If that's what we now mean by "Destination node", we probably need to add a note that the Destination address might not be the address of the Destination node (as stated at https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8200*page-7__;Iw!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-vzjA6Wr8R8o6JrbszFQY-qsZTh5RyS2SWT2$ ).

[RB] Agree. Fixed in the new version.

> 
>    o  Delivery path - A packet's delivery path is a series of nodes that
>       a packet traverses on route to its destination.  The delivery path
>       includes the destination node.
> 
>    o  Segment - A segment is a series of links and nodes in a packet's
>       delivery path.  The IPv6 Routing header steers packets from
>       segment to segment along the delivery path.  If a packet contains
>       a Routing header, its delivery path can contain multiple segments.
>       If a packet does not contain a Routing header, its delivery path
>       contains only one segment.

Are we sure that statement applies to all past, present and future types of routing header? If so, it should be "An IPv6 Routing header steers...".

[RB] This statement applies for all currently defined types. It's harder to predict the future. But I am hoping that the future is informed by the following text from Section 4.4 of RFC 8200:

" The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.  This function is very similar to IPv4's Loose Source
   and Record Route option."
 
>    o  Segment egress node - A segment egress node terminates a segment.
>       When a packet arrives at a segment egress node, its IPv6
>       Destination Address identifies a resource that belongs to the
>       node.  All destination nodes are also segment egress nodes.

That's a significant change. According to RFC 4291, an IPv6 address is assigned to an interface; nothing to do with "resources". If you want an IPv6 address to identify a resource rather than act as a locator, that's an update to 4291, IMHO.

[RB] Agree. Fixed in the next version. s/resource/interface

> 3.  Updates To RFC 8200
...> 3.2.  Updated Text
> 
>    Source nodes can send packets that include extension headers.
>    Extension headers are not inserted by subsequent nodes along a
>    packet's delivery path.
> 
>    The Hop-by-Hop Options header can be processed by any node in a
>    packet's delivery path.

I have long been disturbed by the word "process". Any node can read the value of any extension header (unless encrypted). Firewalls do it and might drop packets as a result. So "process" can't mean "read".
Maybe it means "modify"? But of course options can only be modified in specified ways (and cannot be changed in length).

[RB] Agree. I think that it is fixed in the next version.

[RB] We need to make a distinction between examination and processing. So, I have added a rule that says, "Extension headers can be examined for various purposes (e.g., Firewall filtering) by any node along a packet's delivery path.

>    ... The following headers can be processed by
>    any segment egress node, including the destination node:
> 
>    o  Destination Options header.

Same comment.

> 
>    o  Routing header.

Same comment, but it should add that the spec of any type of routing header must specify precisely what modifications are allowed, and the length of the header must not increase.

[RB] Agree. Fixed in new version.
 
>    The following headers can be processed by the destination node only:
> 
>    o  The Fragment header.
> 
>    o  The Authentication header.
> 
>    o  The Encapsulating Security Payload header.

Do we really need to say that? Once the packet enters the destination node there's no issue.

[RB] Maybe not, but does it hurt to mention it?
 
>    Except for the following fields, extension headers are not modified
>    by nodes along a packet's delivery path:

See, "processed" only means anything if something is modified.

[RB] I'm not sure that I agree. Consider a Destination Options header that precedes the Routing header. It contains an option whose chg-bit is 0. It can be processed by any segment endpoint, but modified by none.

>    o  The Segments Left field in the Routing header.
> 
>    o  Type-specific data in the Routing header.

Are we sure that is enough for all future routing header types? (Actually, there's already a spec for which that rule is probably insufficient:
draft-lc-6man-generalized-srh, which adds a "C-SID left" field to the routing header.)

[RB] I think so. In a Routing header, everything that is not one of the first four fields is Type Specific data.
 
>    o  Option Data in the Destination Options header.
> 
>    Extension headers are not deleted by any node along a packet's
>    delivery path, until the packet reaches the destination node (or each
>    of the set of destination nodes, in the case of multicast).

Again, once the packet is inside the destination node, there's nothing to say.

[RB] We need to say something. If we don't people will assume that extension headers can be deleted by any node along a packets delivery path.

Finally, do we need some comment about AH? Should we require specs to state either that they are incompatible with AH, or to state exactly which fields are mutable for AH purposes?

[RB] Maybe, but I am not sure where that belongs in RFC 8200. Maybe Bob can advise.

                                             Ron


Regards
   Brian Carpenter

On 07-Mar-20 13:47, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Inserting, Processing And Deleting IPv6 Extension Headers
>         Author          : Ron Bonica
> 	Filename        : draft-bonica-6man-ext-hdr-update-01.txt
> 	Pages           : 5
> 	Date            : 2020-03-06
> 
> Abstract:
>    This document provides guidance regarding the processing, insertion
>    and deletion of IPv6 extension headers.  It updates RFC 8200.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bon
> ica-6man-ext-hdr-update/__;!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-
> vzjA6Wr8R8o6JrbszFQY-qsZTh5RyDiuiux$
> 
> There are also htmlized versions available at:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6
> man-ext-hdr-update-01__;!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-vzj
> A6Wr8R8o6JrbszFQY-qsZTh5R_RaW2Oy$ 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> t-bonica-6man-ext-hdr-update-01__;!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZw
> szU62b-vzjA6Wr8R8o6JrbszFQY-qsZTh5R3LzW5-y$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bo
> nica-6man-ext-hdr-update-01__;!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU6
> 2b-vzjA6Wr8R8o6JrbszFQY-qsZTh5R2CiHZik$
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!NE
> t6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-vzjA6Wr8R8o6JrbszFQY-qsZTh5R5vo
> WQxF$
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i-d-
> announce__;!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-vzjA6Wr8R8o6Jrbs
> zFQY-qsZTh5Ry1oSTA3$ Internet-Draft directories: 
> https://urldefense.com/v3/__http://www.ietf.org/shadow.html__;!!NEt6yM
> aO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-vzjA6Wr8R8o6JrbszFQY-qsZTh5R3BOnf0P
> $ or 
> https://urldefense.com/v3/__ftp://ftp.ietf.org/ietf/1shadow-sites.txt_
> _;!!NEt6yMaO-gk!Vg0zJoh5Uh0jsqku3JSdZwszU62b-vzjA6Wr8R8o6JrbszFQY-qsZT
> h5R942qJSv$
>