Re: Next steps on Extension Header Insertion

On 7 Nov. 2016 19:37, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
wrote:
>
>
> > On Nov 7, 2016, at 2:04 AM, Fernando Gont <fgont@si6networks.com> wrote:
> >
> > On 11/02/2016 05:33 PM, otroan@employees.org wrote:
> >> Mark,
> >>
> >>>> I'm just trying to point out that we shouldn't blow this issue out
of proportion. Whatever we end up doing here, it is hard to see it being
particularly important, nor have any big consequences.
> >>>
> >>> I see it having big consequences and being hard to troubleshoot.
> >>>
> >>> Currently, the source IP address in a packet identifies the host that
> >>> is entirely responsible for the construction of the packet. The set of
> >>> values in the IP packet that can be changed in the network is limited
> >>> and well known (HC, TC), and the consequences of those changes failing
> >>> is also limited (packet getting higher forwarding preference, being
> >>> dropped or being forwarded more or less hops than it should).
> >>>
> >>> Allowing EH insertion means the source IP address value isn't true
> >>> anymore - its semantics have changed. It is now only the first
> >>> constructor of the packet, rather than the only one, and any other
> >>> constructors (the EH inserters) are not identified. It's now a
> >>> "multi-source" packet where only the first source is identified.
> >>
> >> Any text describing of EH insertion could possibly work or "allowing
EH insertion" is far out of scope for 2460.
> >
> > Any text that talks about header insertion introduces a change in
> > RFC2460, because RFC2460 does not allow for header insertion.
>
>
> can you point me to the section/paragraph making that statement ?
>

First sentence, second paragraph of "4. IPv6 Extension Headers".

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

The one exception is the HBH EH, which appears directly after the IPv6
header if the packet origin host puts it there.

> Also, if you think rfc2460 denies header insertion, why would you need
new text ?
>

It shouldn't. It does because some people are saying the above is ambiguous.

> Seriously, nothing is prohibited as long as you understand the
consequences.

When it isn't allowed by the specification, claiming it is compliant with
the specification is prohibited.

Changing the specification to support a method doesn't make the problems
with the method go away. If the problems are severe enough, and there are
alterative methods that don't have those problems, the other methods should
be used and possibly specified.

>
As discussed at length, the text should focus on that.
>

I don't think it makes sense to have a part of a specification prohibit
something and then have other text later tacitly allow it.

Regards,
Mark.

> s.
>
>
> >
> > Given the discussion, omission of the topic would be a failure on our
side.
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: fgont@si6networks.com
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>