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

From: "C. M. Heard" <[email-masked]>
Date: Sat, 3 Oct 2015 09:15:49 -0700

I agree that this draft is ready for adoption.  Regarding this:

On Fri, 2 Oct 2015 08:35:03 +1300, Brian E Carpenter wrote:
> Just commenting on two points in Pascal's excellent review:
>
> > => 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.

I concur with both points, i.e., that it would be appropriate to use upper case
RFC 2119 key words and to point to RFC 7045 as a normative reference for
extension header handling by intermediate systems.

I would also like to point out that the current draft text on fragmentation and
header chains, i.e.,

      The Ext Hdrs are all other extension headers that are not included
      in the Unfragmentable headers part of the packet.  For this
      purpose, the IP Authentication Header (AH) and the Encapsulating
      Security Payload (ESP) are not considered extension headers.  The
      Upper-Layer Header is the first upper-layer header that is not an
      IPv6 extension header.  Examples of upper-layer headers include
      TCP, UDP, IPv4, IPv6, ICMPv6, and as noted AH and ESP.

      The Fragmentable Part consists of the rest of the packet after the
      upper-layer header.

doesn't quite get it right: AH should not be treated as an upper-layer header,
and the Fragmentable Part should be the rest of the packet after the
upper-layer header OR any after any header (initial IPv6 header or extension
header) containing a Next Header value of No Next Header.

Even though it is not a good fit for the way the text 2460bis is structured, I
find the description of an IPv6 Header Chain in Section 3 of RFC 7112 to be
much clearer.  For that reason I wonder if it might not be appropriate to add
RFC 7112 as an informative reference.

Mike Heard

---

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

Mike,

> On Oct 3, 2015, at 9:15 AM, C. M. Heard <[email-masked]> wrote:
> 

I had assumed that AH and ESP should be treated the same.  It’s easy to remove AH if that isn’t correct.

I will add the “OR” clause text.  That was an oversight on my part.

> RFC 7112 as an informative reference.

You are right the relevant text in RFC7112 wasn’t very helpful in figuring out how to update the RFC2460.  It basically said:

   When a host fragments an IPv6 datagram, it MUST include the entire
   IPv6 Header Chain in the First Fragment.

That didn’t fit well into the RFC2460 text.  As I noted in another email, I am still looking at improving the text.

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2015 22:09:31 -0300

>> Just commenting on two points in Pascal's excellent review:
[....]
> RFC 7112 as an informative reference.

The more we talk about IPv6 Extension Headers the more I think that at
least the text regarding the processing of IPv6 EHs should probably be
moved out of rfc2460bis. -- it turns out to be a topic by itself (think
e.g. Fred Baker's I-D on HbH processing). And it keeps RFC2460 minimal,
and more in line with what "full standard" is intended to be.

Thanks!

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

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Oct 2015 12:27:28 -0700

Frenando,

> and more in line with what "full standard" is intended to be.

Extension headers are an important part of IPv6.  Moving the processing of extension headers out of the specification would be a very big change, and in my view defeat the reason to go to Internet Standard.

The processing rules would have to be documented somewhere as well, we can’t just remove it.

Bob

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 23 Oct 2015 19:58:31 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Friday, October 23, 2015 3:27 PM
To: Fernando Gont
Cc: C. M. Heard; IPv6 List; Bob Hinden; 6man Chairs
Subject: Re: 6MAN Adoption Call: draft-hinden-6man-rfc2460bis

>Extension headers are an important part of IPv6.  Moving the processing of extension headers out of the specification would be a very big change, and in my view defeat the reason to go to Internet >Standard.

>The processing rules would have to be documented somewhere as well, we can't just remove it.

+1. 

 If any extension header processing is changed from what was proposed in rfc2460 and any subsequent RFC, the WG can expedite the review for changes such as the Fred Baker HBH draft.   

Thanks,

Hemant