<adding the SPRING mailing list, because this is a SPRING draft>
Folks,
Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
define a set of SIDs that have the following things in common:
- they are consumed by the egress node (SL == 0)
- they tell the egress node how to forward the payload into a VPN
If the payload is IPv4, the next-header value in the SRH must be IP4 (value 4).
If the payload is IPv6, the next-header value in the SRH must be IPv6 (value
41).
If the payload is Ethernet, the next-header value in the SRH must be No Next
Header (value 59).
In the interest of consistency, we should probably allocate a new next-header
value for Ethernet and use it.
Ron
Non-Juniper
> -----Original Message-----
> From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Bob Hinden
> Sent: Wednesday, May 8, 2019 12:42 PM
> To: Tom Herbert <t...@herbertland.com>
> Cc: IPv6 List <i...@ietf.org>; Bob Hinden <bob.hin...@gmail.com>
> Subject: Re: SRv6 Network Programming: ENH = 59
>
> Tom,
>
> > On May 8, 2019, at 9:24 AM, Tom Herbert <t...@herbertland.com> wrote:
> >
> > On Wed, May 8, 2019 at 8:48 AM Mark Smith <markzzzsm...@gmail.com>
> wrote:
> >>
> >> On Thu, 9 May 2019 at 00:57, Tom Herbert <t...@herbertland.com>
> wrote:
> >>>
> >>
> >> "If the Payload Length field of the IPv6 header indicates the
> >> presence of octets past the end of a header whose Next Header field
> >> contains 59, those octets must be ignored and passed on unchanged if
> >> the packet is forwarded."
> > Mark,
> >
> > Right, so the first clause say that the No-next-header means there's
> > nothing beyond the header, but the second clause says that if there is
> > something beyond the header it's ignored. So "nothing" can actually be
> > "something" which seems to be contradiction. In practice, this sounds
> > like a wonderful opportunity for a covert channel. I would hope that a
> > receiver of packet with No-next-header followed by a 1000 bytes of
> > "nothing" views the packet with suspicion!
>
> It’s also a great mechanism to tickle buffer overflow bugs. I agree that
> packets like this are suspect, and this is also another good reason to not use
> “No-Next-Header” in SRv6 network programming.
>
> Bob
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=bmZxS1Pe-
> kZHulP5IPA1JPe52WUCDjqLHl0HWAnSazo&s=3N9-
> vv5gp4IjVHnDWJjKOQoLllRYO38bbwWNiuQJVok&e=
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
