RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Mark,

You have hit the nail on the head. Packets should be self-describing. If we are going to ask for a new codepoint, it should represent Ethernet.

                                               Ron

Juniper Business Use Only

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Mark Smith
Sent: Monday, September 16, 2019 10:07 PM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Tom Herbert <tom@herbertland.com>; SPRING WG <spring@ietf.org>; 6man@ietf.org; Pablo Camarillo (pcamaril) <pcamaril@cisco.com>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

On Tue, 17 Sep 2019 at 06:34, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> Pablo,
>
> On 17-Sep-19 07:44, Pablo Camarillo (pcamaril) wrote:
> > Hi Tom,
> >
> > I agree with your suggestion. What do you think of the following text?
> >
> > <OLD>
> >    9.  IANA Considerations
> >
> >
> >       This document requests the following new IANA registries:
> > </OLD>
> >
> > <NEW>
> >    9.  IANA Considerations
> >
> > This document requests IANA to allocate a new IP Protocol Number value for “Opaque” with the following definition:
> > The value TBD in the Next Header field of an IPv6 header or any extension header indicates that the payload is interpreted via a semantics previously established between the source and destination.
>

Is there really any need for this?

An opaque protocol could be encoded using UDP with end-point agreed ephemeral source and destination ports. That would provide a distinguisher in the packet that identifies the end-point agreed semantics. This distinguisher would almost be essential for any troubleshooting based on a packet capture.

Isn't this also creating an opportunity for IETF WGs to bypass IANA, creating their own registry, likely run badly?

Surely all IETF developed protocols should be required to get IANA approved protocol, port, type, code numbers if they need fixed ones, or be required to use dynamic numbers such as UDP ports? Isn't transparency, with exception to when encryption is purposely applied, the fundamental definition of an open protocol?

if this IP protocol value goes ahead, then I think it should be called "Proprietary", and restricted to non-IETF developed protocols.

(And this is ignoring that past proprietary protocols such as EIGRP applied for and received IANA official protocol values.)

Alternatively, isn't this Opaque NH value really saying that the upper layer protocol identifier information has been shifted into the packet's address information?

If payload type and transport layer information is being shifted into the packets' address fields, isn't effectively shrinking the IPv6 address field size from 128 bits to 128 minus the bits required to identify the upper layer protocol type and identifier bits?

Both Multicast formally and anycast informally encodes service or function information in addresses. I still think it is necessary to have upper layer transport protocol headers and identifiers (ports), to allow for the case where a single identifier allocated to a service or function e.g. "Name Resolution", can be implemented using different protocols (UDP/TCP 53 DNS, DoH, DoT).

Another example would be a "Time Synchronisation" service, with a single address, provided over possibly RFC 868 time protocol, NTP, PTP, or Time over HTTPS (https://urldefense.com/v3/__http://phk.freebsd.dk/time/20151129/__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgEXfUWQo-mCw$ )

Regards,
Mark.

> That seems clear enough. I would expect an addition to draft-ietf-opsec-ipv6-eh-filtering, however. Something like:
>
> 3.4.x.  Opaque (Protocol Number=TBD)
> ...
> 3.4.x.3.  Specific Security Implications
>
>    The security implications of the Opaque header are completely unknown.
>
> 3.4.x.4.  Operational and Interoperability Impact if Blocked
>
>    The impact is completely unknown.
>
> 3.4.x.5.  Advice
>
>    Intermediate systems should discard packets containing Opaque unless
>    explicitly configured to allow it.
>
> Regards
>    Brian
>
>
> >
> >       This document requests the following new IANA registries:
> > </NEW>
> >
> > Any feedback or other text proposal is welcome.
> >
> > Many thanks,
> > Pablo.
> >
> >
> > -----Original Message-----
> > From: Tom Herbert <tom@herbertland.com>
> > Date: Thursday, 12 September 2019 at 21:12
> > To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
> > Cc: SPRING WG <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
> > Subject: Re: draft-ietf-spring-srv6-network-programming: NH=59 
> > action item closure
> >
> >     On Thu, Sep 12, 2019 at 10:02 AM Pablo Camarillo (pcamaril)
> >     <pcamaril@cisco.com> wrote:
> >     >
> >     > Hi all,
> >     >
> >     > Following the comments from IETF105, the working group preferred to allocate a new Next Header value.
> >     >
> >     > The authors would like to propose this diff. Any feedback is welcome.
> >     >
> >     > <OLD>
> >     >
> >     >    9.  IANA Considerations
> >     >
> >     >
> >     >
> >     >
> >     >
> >     >       This document requests the following new IANA registries:
> >     >
> >     > </OLD>
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > <NEW>
> >     >
> >     >    9.  IANA Considerations
> >     >
> >     >
> >     >
> >     > This document requests IANA to allocate a new IP Protocol Number value for “SRv6 payload” with the following definition:
> >     >
> >     > The value TBD in the Next Header field of an IPv6 header or any extension header indicates that the payload content is identified via the segment identifier in the IPv6 Destination Address.
> >     >
> >     This seems like an extremely narrow use case to justify an IP Protocol
> >     Number allocation. If this is the route taken, I would suggest to
> >     define something more generic like "Interpreted" which could mean that
> >     there is a next header, but it's interpretation requires information
> >     elsewhere in the packet. That way the number could potentially be used
> >     in other contexts than just SR.
> >
> >     Tom
> >
> >     >
> >     >
> >     >       This document requests the following new IANA registries:
> >     >
> >     > </NEW>
> >     >
> >     >
> >     >
> >     > We would propose to submit a revision with this text on the IANA section of NET-PGM beginning of next week.
> >     >
> >     > Thanks,
> >     > Pablo.
> >     >
> >     > --------------------------------------------------------------------
> >     > IETF IPv6 working group mailing list
> >     > ipv6@ietf.org
> >     > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgEXfUTM5N-q1$ 
> >     > 
> > --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> > Requests: 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > v6__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5h
> > qUgEXfUTM5N-q1$
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgE
> XfUTM5N-q1$
> --------------------------------------------------------------------

_______________________________________________
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgEXfUW1NafP1$ 