Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

[[e-mail]]

Mirja,

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> My discuss is mainly on text in section 4.8 (also based on the tsv-art
> review -> Thanks Martin!):

See also Bob's response to Maritn.

> 
> I find the recommendation to basically just not use hop-by-hop headers in
> section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it
> be maybe time to just deprecate the current hop-by-hop number an assign a
> new one? I know that also has deployment problem but maybe it's worth a
> try. I guess the assignment could happen in a new document though, but
> the deprecation could be done here.

The Hop-by-Hop header (HBH) is a container option. It has the protocol value 0, and has to be first in the header chain, so to make it efficient for routers to check for it's presence.

RFC2460 has:
  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.

The problem with this was that implementations ended up punting packets with the HBH to software, essentially opening up for a DOS attack, which again led operators to filtering out packets with the HBH == 0.
(While at the same time there were no HBH options with cross Internet significance).

How the HBH option could be saved has been discussed for quite some time in the 6MAN working group.
Including a draft: https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
Which conclusion got included into 2460bis.

The working group thought it premature to deprecate the HBH option header.
As a way to "rescue" the HBH option we have made one significant change:

NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that nodes
along a packet's delivery path only examine and process the Hop-by-
Hop Options header if explicitly configured to do so.

Which means by default routers unless they have been configured to process a particular option contained in an HBH option, shall forward the packet as normal. Thereby rectifying the attack vector.

What we lose by this approach is that one cannot use mandatory options anymore. I.e. options that MUST be processed by every router along the packet's path. RFC2675 for example is a mechanism depending on that. In our view this is not a problem, since routers with links with MTU larger than 64K would have to be configured and would be within a controlled domain anyhow.

> 
> This related to this comment from Martin's review, also proposing a
> potential way forward:
> "- Section 4.8. "Defining New Extension Headers and Options":
> It says new hop-by-hop headers must never ever defined. This is
> problematic, as this closing the door forever, even if future instances
> of the IETF do would like to wish to define new hop-by-hop headers. A
> better way would have to say "that new hop-by-hop headers must have IETF
> consensus".

Yes, the door for a new HBH option header container is closed.
Given that this is the signal that every router has to check.
Given that this is a container option one can put whatever one likes into the existing HBH options header, so it would be hard to see the use case for a new one.

> - Section 4.8. "Defining New Extension Headers and Options":
> Also the „not recommended“ to define new extension headers looks strange,
> especially with the phrase "There has to be a very clear justification".
> The term "clear justification" is not an exact engineering specification.
> Why not using "technical protocol specification and real word use case
> required, plus IETF consensus"?"

   Defining new IPv6 extension headers is not recommended.  There has to
   be a very clear justification why any new extension header is needed
   before it is standardized.

The text does state "standardized" though.

Just to remind you that the Destination options header, the HBH options header and the Routing header are all container options, which allows for arbitrary number of TLVs inside. Since extension headers share the numbering space with upper layer protocols, defining new ones would require all implementations parsing header chains (e.g. to do packet filtering on transport headers) would have to be updated. This is the reason for the strict restriction on adding new ones.

> 
> As a side note, there is at least one experimental RFC that defines a
> destination option to be inspected by a network device, given the know
> problems of hop-by-hop option which renders them unusable.

Right, that's a much more costly way of doing it, given that routers would now have to go and hunt for the particular sub option. This also violates RFC2460. And this would obviously neither achieve hop by hop behaviour.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> One question because I'm not sure if I interpret this correct to make it
> part of my discuss:
> Section 4.5: "The number and content of the headers preceding the
> Fragment
>      header of different fragments of the same original packet may
>      differ.  Whatever headers are present, preceding the Fragment
>      header in each fragment packet, are processed when the packets
>      arrive, prior to queueing the fragments for reassembly.  Only
>      those headers in the Offset zero fragment packet are retained in
>      the reassembled packet."
> Does this mean the ECN codepoint (part of the Traffic Class field) is
> copied from the first fragment? This doesn't seem to be correct, however,
> also not sure what the correct answer is. I know this was not changed in
> this revision but maybe we can still get this right.

When fragments are created most of the fields are copied from the IPv6 headers (e.g., Source Address, Destination address, flow label, traffic class, hop limit).  Some like payload length, next header, and hop limit are modified.

If I understand your question, the answer is yes, the ECN code point is copied from the first fragment, but should be the same from all of the fragments.

Best regards,
Ole