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.

>    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://tools.ietf.org/html/rfc8200#page-7).
> 
>    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...".

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

> 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).

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

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

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

>    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.)

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

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?

Regards
   Brian Carpenter

On 07-Mar-20 13:47, internet-drafts@ietf.org 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://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-01
> https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-ext-hdr-update-01
> 
> 
> 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:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 