Using "No next header" to mean "next header Ethernet" seems to me to be
flat wrong.
This also brings up another problem. Having the SID specify the next
header, over-riding the next header value, seems to me to be a recipe
for fragility, likely leading to mis-implementation.
Yours,
Joel
On 5/5/19 8:47 PM, Ron Bonica wrote:
Folks,
According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, when
processing the End.DX2 SID, the Next Header must be equal to 59. Otherwise, the
packet will be dropped.
In the words of the draft, "We conveniently reuse the next-header value 59 allocated
to IPv6 No Next Header [RFC8200]. When the SID corresponds to function End.DX2 and the
Next-Header value is 59, we know that an Ethernet frame is in the payload without any
further header."
According to Section 4.7 RFC 8200, " The value 59 in the Next Header field of an
IPv6 header or any extension header indicates that there is nothing following that
header. 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."
Does the WG think that it is a good idea to reuse the Next Header value 59? Or
would it be better to allocate a new Next Header value that represents Ethernet?
Ron
Juniper Internal
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
