Subject: Scope of draft-hinden-6man-rfc2460bis

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Oct 2015 07:07:40 +0000

Hello Bob:

You raise a great point here: what is the scope of the work that the WG would be taking with this update.

My understanding is that when the group takes on the work, the group will own the right to decide what needs to be changed, and Ole will be responsible to assess consensus. 

IOW, it is too early to reject my questions as not in scope. That much should be addressed with the group; and then the group can accept or reject my points on technical grounds, not procedural ones.

Cheers,

Pascal

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]]
> Sent: mardi 20 octobre 2015 00:20
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; Ole Trøan
> <[email-masked]>; 6man Chairs <[email-masked]>; IPv6
> List <[email-masked]>
> Subject: Re: 6MAN Adoption Call: draft-hinden-6man-rfc2460bis
> 
> Pascal,
> 
> Thanks for your detailed comments.  My thoughts below.
> 
> Thanks,
> Bob
> 
> 
> > On Oct 1, 2015, at 9:25 AM, Pascal Thubert (pthubert)
> <[email-masked]> wrote:
> >
> > Hello Ole:
> >
> > I support this publication.
> >
> > As a last call review, I have a few nits on 07 - sorry in advance if some of
> this was discussed before and I missed it:
> >
> > --------------------------
> >
> > -  On not using uppercase keywords.
> >   The text has a number of lowercase "require" (e.g. ICMP support), "may"
> (eg ignore HbH), "must" (eg HbH must follow IPv6 hdr) etc... which are
> important to interoperability.
> >   And then other occurences of must are not aimed an implementation
> but deal with new specs or deployments rule.
> >   And then there are other terms like "discouraged" on Page 24 which
> yield even less clarity. This one sounds like NOT RECOMMENDED but is it?
> > => Shouldn't we update RFC 2460 to use RFC 2119 syntax when
> appropriate?
> 
> I will send a separate email on this tomorrow,  several others raised this
> issue as well.   I am sure we will discuss it in Yokohama as well.
> 
> >
> > ---------------------------
> >
> > - old text not edited out:
> > "
> > With one exception, extension headers are not examined or processed 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...
> > "
> > Though apparently replaced by the next paragraph:
> > "
> > With one exception, extension headers are not processed 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…
> 
> Thanks for catching this.  It was removed in draft-ietf-6man-rfc2460bis-
> 00.txt
> 
> 
> > "
> >
> 
> > --------------------------------
> >
> >
> > -  "Note: If an intermediate forwarding node examines an extension
> header for any reason, it must do so in accordance with the provisions of
> [RFC7045]."
> > => either the draft is self-contained and that is an indication that should
> be worded as such, or it isn't, in which case there are more details to be
> found in RFC7045.
> >     In the latter case this would mean that 7045 should be a normative
> reference.
> >     Same goes for references to 4302 and 4302: Note 2 page 8 indicates
> that the order in the draft is not self sufficient.
> >
> >
> 
> 
> I think that the wording "it must do so in accordance with the provisions of
> [RFC7045]” is clear.
> 
> RFC2460 didn’t have Normative and Informative references.  I took the
> approach to assigning normative vs. informative references as only
> documents that this specification depends on should be normative.  For
> example the Flow Label specification is normative becaise it defines how to
> use the flow label field.  IPv6 can’t be implemented without it.  In the case
> you raise, this sentence is pointing to an exception to what the first
> sentence in this paragraph said, that is:
> 
>   "With one exception, extension headers are not processed 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”
> 
> I don’t think the behavior in the sentence you refer to is normative.
> 
> Regarding RFC4301 and RFC4302, I don’t think they are required to
> implement this specification.  They are, of course, needed in an IPv6
> implementation, but we don’t try to include every RFC that is needed in an
> IPv6 implementation in the IPv6 protocol specification.
> 
> 
> > ------------------------
> >
> > "
> >    If insufficient fragments are received to complete reassembly of a
> >      packet within 60 seconds of the reception of the first-arriving "
> >
> > Shouldn't this be a constant that would be a recommended value?
> > Is that the value, a maximum value, a recommended value?
> > How does interfere with ULP protocols?
> 
> That is original unchanged text from rfc2460.  It’s out of scope to change
> that in my view.
> 
> >
> > I'll note that some IoT devices have only enough buffer space for one
> packet. I'd agree that such device should not receive long IP packets in
> normal operations.
> > On paper, if a constrained device must wait for one minute before
> dropping the incomplete packet, then it is a one minute blackout for it. And
> it becomes quite easy to DOS a device with just one packet per minute.
> >
> >
> 
> 
> Understood, but don’t think it is an issue for rfc2460bis.  Any device that
> only has enough buffer space for one packet is going to have a lot of
> problems implementing IPv6, and many other IETF protocols.  This is the
> least of it.
> 
> 
> > ------------------------
> > Page 8
> >
> > "
> > It should be noted that due to performance restrictions nodes may
> > ignore the Hop-by-Hop Option header, drop packets containing a hop-by-
> > hop option header, or assign packets containing a hop-by-hop option
> > header to a slow processing path.
> > "
> >
> > I'd suggest to replace "nodes" by "some categories of routers". Same goes
> page 22.
> > Also the behavior may be "likely" in the core of the internet but less so,
> say, in routers that do not have hardware acceleration, and not so at all for
> RPL routers.
> 
> 
> RFC 7045 said “high-performance router”.  I choose to use “nodes" instead
> because I didn’t think we wanted the IPv6 specific to get into different kinds
> of routers.  Technology changes rapidity and we want the basic IPv6
> specification to last for a long time.  Overall, I think the text is clear as to
> what the issue is.
> 
> 
> >
> > Finally, this sentence does not make a recommendation for routers, in
> particular those with hardware forwarding engines, about the treatment for
> an HbH option type.
> > Section 4.2 has that a "node should skip over this option and continue
> processing the header", but then processing the next header is an endpoint
> behavior.
> > Could we clarify whether 4.2 also applies to intermediate routers that
> would "recognize" a HbH header but yet cannot process it for, say,
> performance reasons?
> 
> For the reasons above, I don’t think the IPv6 specification should get into
> recommendations for different kinds of routers.
> 
> The text you refer to is unchanged from rfc2460, so out of scope for this
> project in my view.
> 
> 
> > -----------------------
> >
> > Page 12
> >
> >
> > The intent about HbH is - if I understand well-  to move from a MUST to a
> SHOULD.
> > About:
> > "
> > The Hop-by-Hop Options header is used to carry optional information
> > that must be examined by every node along a packet’s delivery path.
> > "
> > This is an instance where the must lowercase lacks clarity. Could we
> replace must by 'is expected to be' or something?
> >
> 
> Good catch, this should have been changed with the other updates from
> RFC7045.  Thanks.  I will fix in the next version.
> 
> 
> > --------
> >
> > Page 13
> >
> > " This function is very similar to IPv4’s Loose Source and Record
> > Route option."
> >
> > Suggestion to add 'though the record route capability is not provided' - or
> is it expected to be in the future?
> 
> The text you refer to is unchanged in rfc2460, so out of scope for this
> project in my view.
> 
> >
> > --------------
> >
> > Page 16
> >
> > "The Unfragmentable Headers consists of the IPv6 header ..."
> >
> > This section is a hard read because we use unfragmentable to mean
> present in all fragments when the fact that they cannot be cut is a
> consequence of but not their nature; and at the same time the whole
> section explain that extension and upper layer headers are not
> fragmentable anymore but we do not call them unfragmentable; damn.
> > Suggestion is to call the whole set of headers that cannot be fragmented
> "unfragmentable", and call what is today referred to as unfragmentable
> with another name like "replicated" headers or something, to indicate that
> they are replicated in their integrity in all fragments.
> >
> >
> 
> It was a challenge doing this update and keep it in the style of current
> fragmentation text in RFC2460.  The name of these headers needs to be
> consistent with the text:
> 
>       The Unfragmentable Headers consists of the IPv6 header plus any
>       extension headers that must be processed by nodes en route to the
>       destination, that is, all headers up to and including the Routing
>       header if present, else the Hop-by-Hop Options header if present,
>       else no extension headers.
> 
> I don’t think “replicated headers” is better, as it’s not just about replication.
> Other suggestions?
> 
> 
> > --------------
> >
> > P26
> >
> > "
> > As an exception to the default behaviour, protocols that use UDP as a
> > tunnel encapsulation may enable zero-checksum mode for a specific port
> > (or set of ports) for sending and/or receiving.
> > Any node implementing zero-checksum mode must follow the
> requirements
> > specified in "Applicability Statement for the use of IPv6 UDP
> > Datagrams with Zero Checksums" [RFC6936].
> > "
> >
> > The text could be read like this is the sole acceptable exception; RFC 6282
> has another which is valid as well (the payload has a message integrity
> check that is more bobust).
> > Ideally the text should discourage not having a UDP checksum but leave
> the door open for new specs to zero it out when real justifications exist.
> >
> 
> 
> It’s a fair question, but I note that RFC6282 doesn’t update RFC2460.  The
> only exception to not doing UDP checksums the working group has
> accepted is RFC6936.  It might consider others, but I don’t think the
> rfc2460bis update should be adding other exceptions.
> 
> Thanks again for your comments.
> 
> Bob
> 
> 
> 
> > ----------------
> >
> > Cheers,
> >
> > Pascal
> >
> >> -----Original Message-----
> >> From: ipv6 [mailto:[email-masked]] On Behalf Of
> >> [email-masked]
> >> Sent: mercredi 30 septembre 2015 22:16
> >> To: 6man WG <[email-masked]>
> >> Cc: 6man Chairs <[email-masked]>
> >> Subject: 6MAN Adoption Call: draft-hinden-6man-rfc2460bis
> >>
> >> This message starts a two week 6MAN call on adopting:
> >>
> >> Name:	draft-hinden-6man-rfc2460bis
> >> Title:	Internet Protocol, Version 6 (IPv6) Specification
> >> Document date:	2015-09-28
> >> Pages:	36
> >> URL:            https://www.ietf.org/internet-drafts/draft-hinden-6man-
> >> rfc2460bis-07.txt
> >> Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-
> >> rfc2460bis/
> >> Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-rfc2460bis-
> 07
> >> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-
> rfc2460bis-
> >> 07
> >>
> >> as a working group item. Substantive comments and statements of
> >> support for adopting this document should be directed to the mailing
> >> list. Editorial suggestions can be sent to the authors.
> >>
> >> This adoption call will end on October 14th, 2015.
> >>
> >> Regards,
> >>
> >> Bob Hinden & Ole Trøan
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > 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, 24 Oct 2015 08:27:43 +1300

Pascal,

> IOW, it is too early to reject my questions as not in scope. That much should be addressed with the group; and then the group can accept or reject my points on technical grounds, not procedural one…

Sorry, that isn't quite right. The rules about elevating a document to Internet Standard
are a bit special: new features are not an option; removal of unused features is possible;
clarifications and obvious corrections are possible. That is as much procedural
as it is technical.

    Brian