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 protected]> On Behalf Of Mark Smith
Sent: Monday, September 16, 2019 10:07 PM
To: Brian E Carpenter <[email protected]>
Cc: Tom Herbert <[email protected]>; SPRING WG <[email protected]>;
[email protected]; Pablo Camarillo (pcamaril) <[email protected]>
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 <[email protected]>
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 <[email protected]>
> > Date: Thursday, 12 September 2019 at 21:12
> > To: "Pablo Camarillo (pcamaril)" <[email protected]>
> > Cc: SPRING WG <[email protected]>, "[email protected]" <[email protected]>
> > 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)
> > <[email protected]> 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
> > > [email protected]
> > > Administrative Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgEXfUTM5N-q1$
> >
> > >
> > --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list [email protected] Administrative
> > Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > v6__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5h
> > qUgEXfUTM5N-q1$
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgE
> XfUTM5N-q1$
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!R6VTgMTmL2xmewkItMnWbiB25T06w2rZuGndVkYpND8HOGeD5hqUgEXfUW1NafP1$
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
