Subject: draft-ietf-spring-srv6-network-programming: NH=59 action item closure

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 12 Sep 2019 17:01:09 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Sep 2019 13:27:22 -0400

While that proposal does remove the mis-use of next-header 59, it seems 
a very odd use.
It seems to be an effort to avoid needing to register next-header 
values.  Why?

For example, if what is carried after the SRH is an IPv6 packet then the 
next header value for IPv6 (41) would seem the appropriate thing to use. 
  That would produce consistent parsing and clarity.

Yours,
Joel

On 9/12/2019 1:01 PM, Pablo Camarillo (pcamaril) wrote:
> 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.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 12 Sep 2019 17:39:45 +0000

Joel,

This NH value is to be used when the payload does not contain any Internet Protocol.

Cheers,
Pablo.

-----Original Message-----
From: "Joel M. Halpern" <[email-masked]>
Date: Thursday, 12 September 2019 at 19:27
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, SPRING WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    
    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Sep 2019 13:43:50 -0400

1) The way you wrote the text, it would apply to carried IPv4 or carried 
IPv6.

2) If it is carried Ethernet, us 97.
2') If you insist that you need a new format for carried Ethernet after 
SRH, get a code point for that.

3) If there is some other use case, document it and get a code point for 
it.  particularly given that SID meanings may not be registered, 
removing teh ability to tell what the payload is seems a drawback, not a 
benefit.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Sep 2019 12:12:07 -0700

> 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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Xiejingrong <[email-masked]>
Date: Sat, 14 Sep 2019 03:21:50 +0000

I agree with Joel, and strongly opposed to the proposal text !

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

It is a hole digging to exclude other possible ways of indication of 'Opaque Payload format', for example, use IPv6 Source Address, or use options in EH to identify.

As I raise this question in March, I haven't expect the proposal would be so tricky! 

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, September 13, 2019 1:44 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

1) The way you wrote the text, it would apply to carried IPv4 or carried IPv6.

2) If it is carried Ethernet, us 97.
2') If you insist that you need a new format for carried Ethernet after SRH, get a code point for that.

3) If there is some other use case, document it and get a code point for it.  particularly given that SID meanings may not be registered, removing teh ability to tell what the payload is seems a drawback, not a benefit.

Yours,
Joel

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Sep 2019 13:55:35 +1000

On Sat, 14 Sep 2019, 13:22 Xiejingrong, <[email-masked]> wrote:

> "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."
>
> It is a hole digging to exclude other possible ways of indication of
> 'Opaque Payload format', for example, use IPv6 Source Address, or use
> options in EH to identify.
>

Wow, this is getting perverse.

Is there any IPv6 packet field that SPRING aren't willing to abuse for a
non-compliant purpose?

> it.  particularly given that SID meanings may not be registered, removing
> teh ability to tell what the payload is seems a drawback, not a benefit.
>
> Yours,
> Joel
>
> >      > Following the comments from IETF105, the working group preferred
> to
> >      > allocate a new Next Header value.
> >      >
> >      > We would propose to submit a revision with this text on the IANA
> section
> >      > of NET-PGM beginning of next week.
> >      >
> >      > Thanks,
> >      > Pablo.
> >      >
> >      >

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 16 Sep 2019 19:44:07 +0000

Hi Tom,

I agree with your suggestion. What do you think of the following text?

<OLD>
   9.  IANA Considerations

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

Any feedback or other text proposal is welcome.

Many thanks,
Pablo.

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Thursday, 12 September 2019 at 21:12
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: SPRING WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    Tom

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 16 Sep 2019 19:44:22 +0000

Jingrong,

What text do you propose?

Thanks,
Pablo.

-----Original Message-----
From: Xiejingrong <[email-masked]>
Date: Saturday, 14 September 2019 at 05:22
To: "Joel M. Halpern" <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>, SPRING WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    

    Thanks
    Jingrong

    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Friday, September 13, 2019 1:44 AM
    To: Pablo Camarillo (pcamaril) <[email-masked]>; SPRING WG <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    
    
    Yours,
    Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Sep 2019 08:33:47 +1200

Pablo,

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

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Sep 2019 15:03:47 -0700

> I agree with your suggestion. What do you think of the following text?
I think it's good. This probably will also be useful in other contexts
(in GUE for instance).

Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Sep 2019 12:07:03 +1000

> > 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 destinatio…

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 (http://phk.freebsd.dk/time/20151129/)

Regards,
Mark.

---

From: Xiejingrong <[email-masked]>
Date: Tue, 17 Sep 2019 07:29:04 +0000

I think value 97 is quite good and simple.
The Opaque Payload also works for me as you re-written in another email for a more clear and generic usage:
"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."

Thanks
Jingrong

-----Original Message-----
From: Pablo Camarillo (pcamaril) [mailto:[email-masked]] 
Sent: Tuesday, September 17, 2019 3:44 AM
To: Xiejingrong <[email-masked]>; Joel M. Halpern <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Jingrong,

Thanks,
Pablo.

-----Original Message-----
From: Xiejingrong <[email-masked]>
Date: Saturday, 14 September 2019 at 05:22
To: "Joel M. Halpern" <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>, SPRING WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    

    Thanks
    Jingrong

    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Friday, September 13, 2019 1:44 AM
    To: Pablo Camarillo (pcamaril) <[email-masked]>; SPRING WG <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    
    
    Yours,
    Joel

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Sep 2019 14:41:45 +0000

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 <[email-masked]> On Behalf Of Mark Smith
Sent: Monday, September 16, 2019 10:07 PM
To: Brian E Carpenter <[email-masked]>
Cc: Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

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.

> >     > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgEXfUTM5N-q1$ 
> >     > 
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > v6__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5h
> > qUgEXfUTM5N-q1$
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgE
> XfUTM5N-q1$

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

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Sep 2019 14:46:19 +0000

Jingrong,

The value 97 means that the next header is a depicted in Figure 2 of RFC 3378. It should not be used in any other circumstances.

                                                                 Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Xiejingrong
Sent: Tuesday, September 17, 2019 3:29 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>; Joel M. Halpern <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Thanks
Jingrong

-----Original Message-----
From: Pablo Camarillo (pcamaril) [mailto:[email-masked]] 
Sent: Tuesday, September 17, 2019 3:44 AM
To: Xiejingrong <[email-masked]>; Joel M. Halpern <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Jingrong,

Thanks,
Pablo.

-----Original Message-----
From: Xiejingrong <[email-masked]>
Date: Saturday, 14 September 2019 at 05:22
To: "Joel M. Halpern" <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>, SPRING WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    

    Thanks
    Jingrong

    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Friday, September 13, 2019 1:44 AM
    To: Pablo Camarillo (pcamaril) <[email-masked]>; SPRING WG <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

    
    
    Yours,
    Joel
    
    On 9/12/2019 1:39 PM, Pablo Camarillo (pcamaril) wrote:
    >      > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WkDtEqBDAAwCnfBXMrhlStqbgB1qtKYw2_Uj7WKV6jFT_69JGl2B8_G5UVBhHPTm$ 
    >      >
    >      
    > 
    
    _______________________________________________
    spring mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WkDtEqBDAAwCnfBXMrhlStqbgB1qtKYw2_Uj7WKV6jFT_69JGl2B8_G5UVBhHPTm$ 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WkDtEqBDAAwCnfBXMrhlStqbgB1qtKYw2_Uj7WKV6jFT_69JGl2B8_G5UWhP2aev$ 
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Sep 2019 08:33:40 +1200

Ron,

You wrote:

> Isn't this [the Opaque header] also creating an opportunity for IETF WGs to bypass IANA, creating their own registry, likely run badly?

More than that, it's creating an opportunity for operators to bypass IETF standards as well as IANA.

Isn't that the essence of this whole discussion?

They can do it anyway, but defining the code point at least makes it possible for firewalls to discard such traffic if it escapes. Hence my comment about draft-ietf-opsec-ipv6-eh-filtering.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Sep 2019 11:13:18 +1000

On Wed, 18 Sep 2019, 06:33 Brian E Carpenter, <[email-masked]>
wrote:

> Ron,
>
> You wrote:
>
> > Isn't this [the Opaque header] also creating an opportunity for IETF WGs
> to bypass IANA, creating their own registry, likely run badly?
>
> They can do it anyway, but defining the code point at least makes it
> possible for firewalls to discard such traffic if it escapes. Hence my
> comment about draft-ietf-opsec-ipv6-eh-filtering.
>

The word "opaque" means (from Google "meaning opaque"),

"not able to be seen through; not transparent"

If a protocol is opaque or not transparent to the IETF then that would mean
somebody else owns it; it's their property rather than the IETFs.

So somebody else's protocol being referred to by the IETF would fit the
definition of "proprietary":

"relating to an owner or ownership"

So I think Proprietary would be a much more accurate name for this option
if it were to go ahead.

I'd much rather it didn't so we had a transparent and open IETF protocol.

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Sun, 22 Sep 2019 21:05:17 -0700

Hi,

> On Sep 17, 2019, at 6:13 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> On Wed, 18 Sep 2019, 06:33 Brian E Carpenter, <[email-masked]> wrote:
> Ron,
> 
> You wrote:
> 
> If a protocol is opaque or not transparent to the IETF then that would mean somebody else owns it; it's their property rather than the IETFs.
> 
> So somebody else's protocol being referred to by the IETF would fit the definition of "proprietary":
> 
> So I think Proprietary would be a much more accurate name for this option if it were to go ahead.
> 

I also agree.

Since I have started doing a little Wireshark development, I think it’s important that new protocols be possible to parse with network debugging tools like Wireshark.   Having a code point that does not have a reference that points to how to parse it makes network debugging difficult if not impossible.

I would prefer a code point that have both a descriptive name and points to an open specification for what the protocol looks like that follows.  Especially since this work is being done in the IETF.

Bob