Subject: Re: 6MAN Adoption Call: draft-hinden-6man-rfc2460bis

From: Timothy Winters <[email-masked]>
Date: Thu, 1 Oct 2015 08:22:19 -0400

I also support the adoption of this draft as a 6MAN wg item.

~Tim

On Thu, Oct 1, 2015 at 12:34 AM, Jouni <[email-masked]> wrote:

> I support the adoption of this draft as a 6man wg item. It was about time
> ;)
>
> A question. What will happen to those RFCs that now get incorporated into
> RFC2460bis?
> Will those be obsoleted by RFC2460bis?
>
> - Jouni
>
>
> > On 30 Sep 2015, at 13:15, [email-masked] wrote:
> >
> > 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
> --------------------------------------------------------------------
>

-- 

Timothy Winters
UNH-IOL Senior Executive, Software and IP Networking
603-421-4987
IOL INTACT <https://www.iol.unh.edu/solutions/test-tools/intact>, an IPv6
test tool, helped participants verify products and prototypes at the CEA’s
IPv6 plugfest.
Read more at: http://bit.ly/1IOKePo

---

From: Brian Haberman <[email-masked]>
Date: Thu, 1 Oct 2015 08:33:20 -0400

Hi Jouni,

On 10/1/15 12:34 AM, Jouni wrote:
> I support the adoption of this draft as a 6man wg item. It was about time ;)
> 
> A question. What will happen to those RFCs that now get incorporated into RFC2460bis?

If the contents of those RFCs are fully incorporated in 2460bis, then
they should be marked as Obsoleted by 2460bis.

Regards,
Brian

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Oct 2015 16:25:26 +0000

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?

---------------------------

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

--------------------------------

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

------------------------

"
    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?

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.

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

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?

-----------------------

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?

--------

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?

--------------

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.

--------------

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.

----------------

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
> 
> for adopting this document should be directed to the mailing list. Editorial
> suggestions can be sent to the authors.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2015 08:35:03 +1300

> => Shouldn't we update RFC 2460 to use RFC 2119 syntax when appropriate?

I would tend to agree with that. Given that IPv6 was still quite new when
2460 was published it was reasonable to be a little imprecise, but I think
we should be able to do this now (and it will actually make it easier to
show that the criteria for Internet Standard are satisfied).

> In the latter case this would mean that 7045 should be a normative reference.

Technically, that's a downref since we are aiming at Internet Standard. However,
this is allowed by the simple procedure in BCP 97 (RFC 4897). So I agree.
The same applies to all the normative references that are not Internet Standards.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2015 15:02:35 -0500

> show that the criteria for Internet Standard are satisfied).

+1 I'm all for this.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 1 Oct 2015 20:30:27 +0000

> This adoption call will end on October 14th, 2015.

I'm fine with almost all of this draft, except for the continued silence on both bit numbering and byte transmission order conventions. Not sure why the opposition to lifting Appendix B from RFC 791 and pasting it here, verbatim.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2015 15:44:03 -0500

On 10/01/2015 11:25 AM, Pascal Thubert (pthubert) wrote:
> - 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
> identified in the Destination Address field of the IPv6 header... "
> 
> -  "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.

Why not keep the definition/specification of EHs specified in RFC2460,
but point to RFC7045 for anything that has to do with how to process
them, etc.?

This would make for a more minimalistic 2460bis.

> " 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?

FWIW, This essentially influences the maximum packet lifetime, and has
implications on values that depend on it, such as e.g. TCP'S TIME-WAIT
state.

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

Out of scope, but: Can such a device be said to be IPv6 compliant?

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

Fred Baker's I-D regarding HBH processing comes to mind. Again if all
processing of EHs is kept out of this document, the problem remains
tractable.

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

I'd say: use RFC2119 language. That's the whole point of it, isn't it?

Cheers,

---

From: [email-masked]
Date: Thu, 1 Oct 2015 23:43:12 +0200

Brian,

> show that the criteria for Internet Standard are satisfied).

I think you can argue that 2460 already uses the key words defined in 2119.
from what I can see 2119 doesn't require the key words to be capitalized, although they "typically" would.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2015 11:26:21 +1300

> from what I can see 2119 doesn't require the key words to be capitalized, although they "typically" would.

True, but I find that the advantage of the upper case usage is mainly in
detecting that remaining lower case mays and shoulds are in fact ambiguous.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2015 17:54:49 -0500

> from what I can see 2119 doesn't require the key words to be capitalized, although they "typically" would.

I just checked RFC2119 and, strictly speaking, you seem to be right.

However:

1) I think that many of us only take uppercase keywords as requirements.
Otherwise, it's "up to the reader" what must be consider a formal
requirement, and what may be considered "colloquial" use of these terms.

2) RFC1122, which has not been formally updated by RRFC2119, says:

      1.3.2  Requirements

         In this document, the words that are used to define the
         significance of each particular requirement are capitalized.

[...]
         An implementation is not compliant if it fails to satisfy one
         or more of the MUST requirements for the protocols it
         implements.  An implementation that satisfies all the MUST and
         all the SHOULD requirements for its protocols is said to be
         "unconditionally compliant"; one that satisfies all the MUST
         requirements but not all the SHOULD requirements for its
         protocols is said to be "conditionally compliant".

So this would be yet another argument in favor of uppercase RFC2119 words.

Just my two cents,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: David Farmer <[email-masked]>
Date: Fri, 2 Oct 2015 01:14:38 -0500

> On Oct 1, 2015, at 17:26, Brian E Carpenter <[email-masked]> wrote:
> 

While Ole is technically correct, for an abundance of clarity that Internet Standard status deserves, please let's use the upper case form of the RFC2119 keywords.

Thanks
-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Oct 2015 08:59:54 +0000

Hello Fernando:

> implications on values that depend on it, such as e.g. TCP'S TIME-WAIT

This is really the very beginning of the answer I'm after; the real questions look like:

- Not all traffic is TCP. Lot of UDP around, and we have given rules on how to use UDP (RFC 5405) to be a good citizen of the Internet. Are they affected by this value?
- Original tunings of the transport protocols were designed for network latencies that would reach minutes. This can still happen in some networks, don't take me wrong. But usually the worst case interval between fragments will be below ms and there could be floods of fragments. Is 1 minute always realistic?
- Even if it is TCP; what happens to TCP flows if we tune that value from a split second to an hour? Is there any experimental research that shows that 1 minute is a sweet spot of some form, and for which traffic?
- TCP's reaction will impact the application behavior. E.g. a retry may come too late for the application acceptable latency, which is why the whole reliable UDP / SCTP story started in the first place. Are we changing the application experience by tuning that value? In which way?

If we do not have all these answer, my recommendation is to leave some opening by having a default and a range that is wide enough for real world use cases.

> > minute blackout for it. And it becomes quite easy to DOS a device with
> > just one packet per minute.
> 
 
Not out of scope.  My point, actually. 

IPv6 is and will continue to be what this document and this group will make it. And by establishing rules, we'll collectively include or exclude groups of behaviors and devices.  As it goes IPv6 is evolving, e.g. the discussion on flow label, and the boundaries may change.

The way HbH or UDP checksum are discussed is core minded, and not taking the path of being more inclusive to new usages of IPv6.
One could argue that IoT is (too?) extreme. I'd argue that switching packet so fast that you cannot process HbH is also extreme.
What we include or exclude is our decision, and we have the responsibility to listen to all parties so we make it consciously.

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

And in particular here, my suggestion is not to use RFC2119 language, since this text is not the place where the switch from MUST to SHOULD is occurring. 
This is a leftover that would have been confusing if left as is.

Cheers

Pascal

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Oct 2015 12:15:29 +0200

[...]

> Out of scope, but: Can such a device be said to be IPv6 compliant?

This is a very relevant question.

Many devices labelled IoT run something else than rfc2460 IPv6.  E.g. 
the IPv6 base header is stripped.

Contradiction: even though IPv6 is space enough to accommodate numerous 
IoT devices they dont have enough space to accomodate IPv6 base headers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Oct 2015 12:18:31 +0200

> This adoption call will end on October 14th, 2015.

I support adoption.

Alex

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 2 Oct 2015 11:32:47 +0000

I also support the 6MAN WG adoption of this draft.

Can only bring stability and make thing clearer

-éric

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 2 Oct 2015 14:53:07 +0200

Hi,

I support adoption of this draft as WG item.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Oct 2015 08:43:52 +1300

On 02/10/2015 23:15, Alexandre Petrescu wrote:
> Many devices labelled IoT run something else than rfc2460 IPv6.  E.g. the IPv6 base header is stripped.
> 
> Contradiction: even though IPv6 is space enough to accommodate numerous IoT devices they dont have enough space to accomodate
> IPv6 base headers.

If there's a class of devices that can be assigned IPv6 addresses but can only support
a mini-IPv6 packet format, which implies that their connection to the rest of the
world will be via a proxy or ALG, that's not really a contradiction. It just needs
defining (but not in this WG).

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Oct 2015 20:24:29 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, October 02, 2015 3:44 PM
To: Alexandre Petrescu; [email-masked]
Subject: Re: IPv6 IoT devices

>If there's a class of devices that can be assigned IPv6 addresses but can only support a mini-IPv6 packet format, which implies that their connection to the rest of the world will be via a proxy or ALG, >that's not really a contradiction. It just needs defining (but not in this WG).

+1.

A link-specific (e.g., IoT link) document can add additional IPv6 requirements.   We should not clutter and special-case the core IPv6 RFC2460bis document.

Thanks,

Hemant

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 2 Oct 2015 17:39:26 -0400

On Fri, Oct 2, 2015 at 4:24 PM, Hemant Singh (shemant) <[email-masked]>
wrote:

> >If there's a class of devices that can be assigned IPv6 addresses but can
> only support a mini-IPv6 packet format, which implies that their connection
> to the rest of the world will be via a proxy or ALG, >that's not really a
> contradiction. It just needs defining (but not in this WG).
>
> +1.
>
> A link-specific (e.g., IoT link) document can add additional IPv6
> requirements.   We should not clutter and special-case the core IPv6
> RFC2460bis document.
>
> +1.

BTW, I am unaware of any 6lo proposal that doesn't support 1280 octet MTUs.
The principal reason for compressed headers is to conserve b/w and power.
But was the original question whether a host that could only receive a
_single_
1280 octet MTU be considered IPv6 compliant?

Cheers, Kerry

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Oct 2015 13:21:07 +1300

> 1280 octet MTU be considered IPv6 compliant?

I don't think so; reassembly of fragments is not optional. RFC 2460 says:

   A node must be able to accept a fragmented packet that, after
   reassembly, is as large as 1500 octets.  A node is permitted to
   accept fragmented packets that reassemble to more than 1500 octets.
   An upper-layer protocol or application that depends on IPv6
   fragmentation to send packets larger than the MTU of a path should
   not send packets larger than 1500 octets unless it has assurance that
   the destination is capable of reassembling packets of that larger
   size.

So presumably a node that can only receive a single 1500 octet MTU is
compliant, but it MUST be able to accept it in two fragments.

    Brian

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 3 Oct 2015 01:32:33 +0000

> Contradiction: even though IPv6 is space enough to accommodate 
> numerous IoT devices they dont have enough space to accomodate
> IPv6 base headers.

If there's a class of devices that can be assigned IPv6 addresses but can only support a mini-IPv6 packet format, which implies that their connection to the rest of the world will be via a proxy or ALG, that's not really a contradiction. It just needs defining (but not in this WG).

   Brian
[SC>] 

6lo WG works on IPv6 on constrained node networks using compressed IPv6 header and optimized ND when needed.

If  further change is needed for Ipv6 extension header etc. -- bringing the idea to 6loWG  would be welcome. We can then work with 6man chairs to co-ordinate the work.

-Samita (6lo co-chair )

---

From: Bob Hinden <[email-masked]>
Date: Sun, 18 Oct 2015 22:44:36 -0700

Brian,

> On Oct 1, 2015, at 5:33 AM, Brian Haberman <[email-masked]> wrote:
> 
> Hi Jouni,
> 

I think there are several categories.

Some of the updating document have been incorporated by reference, I don’t think these should be obsoleted.  For example, RFC6437.

Several updating RFCs update several RFCs, I don’t think these should be obsoleted until the other RFCs are revised.

The remainder, the with a few exception like 5095 that are very focused,  provide a lot of background material on why the update was made.  This material has not been incorporated in to rfc2460bis, so I don’t think they should be obsoleted.

I will take a close look and make a recommendation to the w.g.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Oct 2015 15:20:27 -0700

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

> Destination Address field of the IPv6 header…

Thanks for catching this.  It was removed in draft-ietf-6man-rfc2460bis-00.txt

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.

That is original unchanged text from rfc2460.  It’s out of scope to change that in my view.

> 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 pa…

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.

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.

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

Good catch, this should have been changed with the other updates from RFC7045.  Thanks.  I will fix in the next version.

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

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?

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Oct 2015 14:44:30 -0700

Bert,

> On Oct 1, 2015, at 1:30 PM, Manfredi, Albert E <[email-masked]> wrote:
> 

I don’t have a strong opinion on this.  I would like to hear other opinions on your proposal.  We could add it as it clearly a clarification, not a change to current implementation.  One approach would be to add a sentence that the Data Transmission Order is the same as Appendix B of RFC791.  Another is to create a new appendix in rfc2460bis.

For reference the text from RFC791 is below.

Bob

Data Transmission Order

The order of transmission of the header and data described in this
document is resolved to the octet level.  Whenever a diagram shows a
group of octets, the order of transmission of those octets is the normal
order in which they are read in English.  For example, in the following
diagram the octets are transmitted in the order they are numbered.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       2       |       3       |       4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       5       |       6       |       7       |       8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       9       |      10       |      11       |      12       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Transmission Order of Bytes

                               Figure 10.

Whenever an octet represents a numeric quantity the left most bit in the
diagram is the high order or most significant bit.  That is, the bit
labeled 0 is the most significant bit.  For example, the following
diagram represents the value 170 (decimal).

                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |1 0 1 0 1 0 1 0|
                           +-+-+-+-+-+-+-+-+

                          Significance of Bits

                               Figure 11.

Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.  When
a multi-octet quantity is transmitted the most significant octet is
transmitted first.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Oct 2015 13:18:59 +1300

On 22/10/2015 10:44, Bob Hinden wrote:
> I don’t have a strong opinion on this.  I would like to hear other opinions on your proposal.  We could add it as it clearly a clarification, not a change to current implementation.  One approach would be to add a sentence that the Data Transmission Order is the same as Appendix B of RFC791.  

That seems simplest.

   Brian

> Another is to create a new appendix in rfc2460bis.
>

---

From: [email-masked]
Date: Thu, 22 Oct 2015 09:01:27 +0200

>> I don’t have a strong opinion on this.  I would like to hear other opinions on your proposal.  We could add it as it clearly a clarification, not a change to current implementation.  One approach…

or just:
"All frame formats are in big-endian network byte order."

I think the question of how many bits there are in a byte is clear for anyone reading 2460bis in 2015.

Best,
Ole

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 22 Oct 2015 21:16:51 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 22, 2015 03:01

> >> I don’t have a strong opinion on this.  I would like to hear other
> opinions on your proposal.  We could add it as it clearly a clarification,
> not a change to current implementation.  One approach would be to add a
> sentence that the Data Transmission Order is the same as Appendix B of
> RFC791.
> >
> > That seems simplest.
> 
> or just:

I think there are two things that the referencing or quoting of RFC 791 Appendix B would accomplish:

1. To clarify the byte transmission order, and how these bytes are represented on a page.

2. Another important clarification is the Internet bit numbering convention, which is opposite that of many older schemes, and is independent of the layers 1 and 2 used. Numbering the most significant bit 0, and showing it on the left of the page, whether this bit gets transmitted first or last by the physical layer.

Both of these conventions are important to clarify, and there's no mention of this in RFC 2460, not even a hint in the pictograms. And hard as it might be to believe, even in 2015, people do not adhere to these conventions. So something that clearly states them would be real nice.

Bert