Subject: Destination Option Metaquestion

From: Ronald Bonica <[email-masked]>
Date: Tue, 16 Sep 2014 02:54:59 +0000

Folks,

Theoretically, any piece of information that needs to be passed from an IPv6 source to an IPv6 destination can be encoded in the following ways:

- in an IPv6 Destination Option
- as IPv6 payload

Does any RFC offer guidance regarding what types of information CAN be encoded in Destination Options? What types of information MUST NOT be encoded in destination options? If not, should such a document exist? 

I think that many of us have a common opinion regarding this question. But is it articulated anywhere?

Ron Bonica

---

From: George Michaelson <[email-masked]>
Date: Tue, 16 Sep 2014 13:22:01 +1000

based on the EH thing fernando and jen presented to IEPG I tend to payload.
it looks like adding new magic in headers is asking deployed boxes to deny
you service.

"but thats just me"

On Tue, Sep 16, 2014 at 12:54 PM, Ronald Bonica <[email-masked]> wrote:

> Folks,
>
> Theoretically, any piece of information that needs to be passed from an
> IPv6 source to an IPv6 destination can be encoded in the following ways:
>
> Does any RFC offer guidance regarding what types of information CAN be
> encoded in Destination Options? What types of information MUST NOT be
> encoded in destination options? If not, should such a document exist?
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 15 Sep 2014 20:32:28 -0700

On 9/15/14 7:54 PM, Ronald Bonica wrote:
> Folks,
> 
> Theoretically, any piece of information that needs to be passed from
> an IPv6 source to an IPv6 destination can be encoded in the following
> ways:
> 
> - in an IPv6 Destination Option - as IPv6 payload
> 
> Does any RFC offer guidance regarding what types of information CAN
> be encoded in Destination Options? What types of information MUST NOT
> be encoded in destination options? If not, should such a document
> exist?
> 
> I think that many of us have a common opinion regarding this
> question. But is it articulated anywhere?

You need to use tunnel mode ESP in general if you want to insure the
confidentiality of the contents of a header and potentially it's
existence..

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Sep 2014 15:57:42 +1200

Hi Ron,

> - in an IPv6 Destination Option

You could add to the list

 - in an IPv6 Extension Header

> Does any RFC offer guidance regarding what types of information CAN be encoded in Destination Options? What types of information MUST NOT be encoded in destination options? If not, should such a do…

If you read draft-gont-opsec-ipv6-eh-filtering (you wrote it ;-)
and draft-gont-6man-ipv6-opt-transmit (oh, that one too ;-),
I think it becomes clear that the question is the other way
round: what types of information are likely to lead firewalls
to discard destination options or extension headers?

On the other hand, if you push data up into the payload, you
increase the likelihood of deep packet inspection, so in a way
you can't win.

Another way that you can't win is by encrypting these data.
In that case, DPI will fail and you increase the likelihood
of default deny.

> I think that many of us have a common opinion regarding this question. But is it articulated anywhere?

I'm not even sure I know what that opinion is. Like to share?

There are some generalities in RFC 6709 that in a sense apply
to all new extension headers and options, but nothing specific.

   Brian

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 16 Sep 2014 18:50:04 +0000

Hi Brian,

How does the following proposal sound?

"A piece of information MUST be encoded as an IP destination option it is used by the IP layer on the destination node for some reason beyond passing it up to a higher layer. However, once the information is used, it is passed up to the higher layer.

Otherwise, the information MUST be encode as IPv6 payload."

                                                                         Ron

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, September 15, 2014 11:58 PM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: Destination Option Metaquestion
> 
> Hi Ron,
> 
> If you read draft-gont-opsec-ipv6-eh-filtering (you wrote it ;-) and draft-
> gont-6man-ipv6-opt-transmit (oh, that one too ;-), I think it becomes clear
> that the question is the other way
> round: what types of information are likely to lead firewalls to discard
> destination options or extension headers?
> 
> On the other hand, if you push data up into the payload, you increase the
> likelihood of deep packet inspection, so in a way you can't win.
> 
> In that case, DPI will fail and you increase the likelihood of default deny.
> 
> There are some generalities in RFC 6709 that in a sense apply to all new
> extension headers and options, but nothing specific.
> 
>    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2014 20:05:48 +0000

Hi Ron,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Tuesday, September 16, 2014 11:50 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: RE: Destination Option Metaquestion
> 
> Hi Brian,
> 
> "A piece of information MUST be encoded as an IP destination option it is used by the IP layer on the
> destination node for some reason beyond passing it up to a higher layer. However, once the information
> is used, it is passed up to the higher layer.
> 

That would not follow for tunnels. For tunnels, the ingress is the
source, the egress is the destination and the IPv6 payload is the
tunneled packet. The egress gets to inspect the information encoded
in the IPv6 header supplied by the ingress, but the tunnel is not
permitted to alter the contents of the tunneled packet.

Thanks - Fred
[email-masked]

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 16 Sep 2014 20:19:50 +0000

> 
> That would not follow for tunnels. For tunnels, the ingress is the source, the
> egress is the destination and the IPv6 payload is the tunneled packet.
[RPB] 
So far, I am with you.
 The
> egress gets to inspect the information encoded in the IPv6 header supplied
> by the ingress, but the tunnel is not permitted to alter the contents of the
> tunneled packet.
> 

[RPB] 
Why would it want to?

                      Ron

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Sep 2014 20:25:25 +0000

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Tuesday, September 16, 2014 1:20 PM
> To: Templin, Fred L; Brian E Carpenter
> Cc: [email-masked]

OK.

> > by the ingress, but the tunnel is not permitted to alter the contents of the

It wouldn't if the encapsulation header inserted by the ingress had
all of the information needed by the egress. That's all I'm saying...

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Sep 2014 10:59:13 +1200

Hi Ron,

On 17/09/2014 06:50, Ronald Bonica wrote:
> "A piece of information MUST be encoded as an IP destination option it is used by the IP layer on the destination node for some reason beyond passing it up to a higher layer. 

I'm not at all sure we should use normative language for this.
It seems much more like advice to designers than a standards issue.
I agree with the spirit though (and the same would apply
to extension headers). Clearly, given the middlebox world we live
in, people need to have very, very strong arguments to define
either of them these days.

> However, once the information is used, it is passed up to the higher layer.

It might be, but only beyond the transport layer if the socket API
supports it.

> Otherwise, the information MUST be encode as IPv6 payload."

Maybe the advice should discuss whether that means as a transport
layer option or above, discuss encryption, etc. I don't think it can be
said in a couple of sentences.

    Brian

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 18 Sep 2014 17:51:52 +0000

Brian,

Do you think that an ID is required, or is this best left as folklore?

                                                         Ron

> Sent: Tuesday, September 16, 2014 6:59 PM
> To: Ronald Bonica
> Cc: [email-masked]
> > "A piece of information MUST be encoded as an IP destination option it is
> used by the IP layer on the destination node for some reason beyond
> passing it up to a higher layer.
> 
> I agree with the spirit though (and the same would apply to extension
> headers). Clearly, given the middlebox world we live in, people need to have
> very, very strong arguments to define either of them these days.
> 
> It might be, but only beyond the transport layer if the socket API supports it.
> 
> Maybe the advice should discuss whether that means as a transport layer
> option or above, discuss encryption, etc. I don't think it can be said in a
> couple of sentences.
> 
>     Brian
> 
> >
> >
> > Ron
> >
> >>> an
> >>> be
> >> If you read draft-gont-opsec-ipv6-eh-filtering (you wrote it ;-) and
> >> draft- gont-6man-ipv6-opt-transmit (oh, that one too ;-), I think it
> >> becomes clear that the question is the other way
> >> round: what types of information are likely to lead firewalls to
> >> discard destination options or extension headers?
> >>
> >> On the other hand, if you push data up into the payload, you increase
> >> the likelihood of deep packet inspection, so in a way you can't win.
> >>
> >> There are some generalities in RFC 6709 that in a sense apply to all
> >> new extension headers and options, but nothing specific.
> >>
> >>    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Sep 2014 10:24:56 +1200

> Do you think that an ID is required, or is this best left as folklore?

Realising that the current IAB-approved folklore on protocol
extensions (RFC 6709) isn't sufficient guidance in this case,
I'm inclined to the view that some specific *written* guidance for
people who think that an extension header or IPv6 option will solve
their problem is a good idea. But maybe we should wait until the
present set of drafts (which mainly seem to be draft-gont-*) has
stabilised, so that there is a firm basis for writing the guidance?

So my answer to you is: yes, an I-D, but not quite yet.

    Brian