Subject: blanks

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 15:29:34 +0000

Hi,

Sometimes, an IPv6 node may have nothing useful to say but wants
to make a little noise anyway. In those cases, it should be able
to fire off a "blank" that gets through the network to the final
destination but then gets dropped at the destination's doorstep.
Here, I define a blank as any IPv6 packet that contains the value
"No Next Header" in the ultimate (i.e., outermost) Next Header
field. The IPv6 input process of the destination will receive the
packet and delete it once it sees that there is no upper layer
header following the IPv6 header.

As I said, on the surface all this does is makes a little noise.
But in some cases, useful information can be conveyed such as in
a Destination Option. Is it worth writing a little 2-3 page
informational document describing this?

Thanks - Fred
[email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Jul 2014 11:36:40 -0400

Please don't.  There is no need to standardize such a mechanism.

On 7/17/14 11:29 AM, Templin, Fred L wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 15:38:12 +0000

Hi,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Thursday, July 17, 2014 8:37 AM
> To: [email-masked]
> Subject: Re: blanks
> 

Agreed; that is why I said "informational".

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Jul 2014 11:41:16 -0400

Let me try again...

> Agreed; that is why I said "informational".

Regardless of the status, there are a myriad of ways to send a "blank"
packet.  Why document one way?  I see no benefit to writing a document
on how to send such a packet.  If you want to send such a packet, go for
it.  There is nothing stopping you and there is no need to publish how
you did so.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 15:52:09 +0000

Hi Brian,

> Sent: Thursday, July 17, 2014 8:41 AM
> To: [email-masked]
> Subject: Re: blanks
> 
> Let me try again...
> 
> packet.  Why document one way?

This way has I think a fairly unique property that the packet makes
it through the network to the IP layer of the final destination where
it can be examined for things such as Destination Options, but is then
dropped without ever disturbing any upper layer protocols. The network
sees a flow of packets, the destination's interface input counters get
incremented, etc. exactly as if the thing was a live IPv6 packet, but
then the blank falls harmlessly into the bit bucket. 

> I see no benefit to writing a document
> on how to send such a packet.

I was thinking more of a document that says "why" instead of "how".
As in a few potential use cases.

> If you want to send such a packet, go for

Right; not how but why.

Thanks - Fred

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 17 Jul 2014 15:54:01 +0000

Fred

Perhaps worth describing on this list and with a couple of sentences, the
'why' as you wrote...

Teredo bubbles have there for a while ;-)

-éric

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Jul 2014 11:58:27 -0400

Fred,

>> it.  There is nothing stopping you and there is no need to publish how

Still don't see the benefit.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 16:12:55 +0000

> Still don't see the benefit.

Blanks can be sent at the discretion of the sender for the benefit
of the receiver(s). Just a little blip to let the receiver(s) know
that the sender is still alive and w/o having to disturb any upper
layer protocols. The network path(s) between the sender and
receiver(s) may also be interested to see some occasional traffic.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Jul 2014 12:17:00 -0400

> receiver(s) may also be interested to see some occasional traffic.

So, you are basically describing RFC 5880 (albeit in one direction, maybe).

I will repeat myself once more and then shut up...

I don't see the benefit of documenting the "why" in an RFC.  Your
original note read like you wanted to describe the "how" and I don't see
the need either since this is just noise that can be generated in a
multitude of ways.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 16:24:38 +0000

Hi Brian,

> Sent: Thursday, July 17, 2014 9:17 AM
> To: [email-masked]
> Subject: Re: blanks
> 
> 
> 

49 pages - wow, that's a lot of text! I was thinking 2-3 pages.

> I don't see the benefit of documenting the "why" in an RFC.

I'm not pushing hard for this - just testing the waters before
wasting Internet Draft submission resources, and perhaps to
introduce a new term.

> Your original note read like you wanted to describe the "how"

Apologies.

> and I don't see

On that, I think I made the point that this manner has some
fairly unique and desirable properties.

Thanks - Fred

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Jul 2014 12:25:18 -0400

Brian Haberman <[email-masked]> wrote:
    >> Blanks can be sent at the discretion of the sender for the benefit of
    >> the receiver(s). Just a little blip to let the receiver(s) know that
    >> the sender is still alive and w/o having to disturb any upper layer
    >> protocols. The network path(s) between the sender and receiver(s) may
    >> also be interested to see some occasional traffic.
    >>

    > original note read like you wanted to describe the "how" and I don't
    > see the need either since this is just noise that can be generated in a
    > multitude of ways.

It would definitely be an odd packet for someone to notice in the middle.
It could cause a device in the middle to do the wrong thing (such as look for
port numbers where none exist).  That it is a legitimate activity might be
implicit in the IPv6 documents; but it is explicitely called out?

I know that we talked about doing exactly such a thing inside IPsec tunnels
as keepalives as well.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: James R Cutler <[email-masked]>
Date: Thu, 17 Jul 2014 12:46:41 -0400

> [email-masked]

I would suggest that an IPv6 node that is that lonely needs more attention from the System Manager. Making noise to disturb other nodes is not a particularly friendly act.

If the business purpose is to determine ongoing connectivity for a business activity, the an application level query and response is appropriate.  For generic connectivity probing, ECHO is appropriate, but not just because a node is lonely or bored.

James R. Cutler
[email-masked]
PGP keys at http://pgp.mit.edu

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 16:55:34 +0000

Hi Michael,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Thursday, July 17, 2014 9:25 AM
> To: Brian Haberman
> Cc: [email-masked]
> Subject: Re: blanks
> 
> 

Perhaps in some networks, but maybe not all.

> port numbers where none exist).

That sounds like broken networking gear - it would be good to
find such gear and fix it.

> That it is a legitimate activity might be

I think the specs are silent, but blanks are built in just the same.

> I know that we talked about doing exactly such a thing inside IPsec tunnels

I'll add this to my use case list.

Thanks - Fred

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Jul 2014 14:02:49 -0400

> Perhaps in some networks, but maybe not all.

I'm saying this from the point of view of someone who is looking at the
traffic in the middle trying to figure out why:

    >> It could cause a device in the middle to do the wrong thing (such as
    >> look for port numbers where none exist).

    > That sounds like broken networking gear - it would be good to find such
    > gear and fix it.

there is this gear in the middle that is failing; because it was misdesigned.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 18:41:08 +0000

Hi Michael,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Thursday, July 17, 2014 11:03 AM
> To: Templin, Fred L
> Cc: Brian Haberman; [email-masked]
> Subject: Re: blanks
> 
> 

Understood. But, I think there will be uses for IPv6 in networks
besides the public Internet where we might have a bit more control
over the type of networking gear we deploy.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2014 18:54:18 +0000

> over the type of networking gear we deploy.

Let me correct myself because I don't want to exclude the case of
operating over the public Internet. If a node sends a legitimate
IPv6 packet that is perfectly compliant with the specs and some
fragile piece of networking gear goes belly-up, whose fault is that?

Thanks - Fred

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Jul 2014 15:04:49 -0400

> operating over the public Internet. If a node sends a legitimate IPv6
    > packet that is perfectly compliant with the specs and some fragile
    > piece of networking gear goes belly-up, whose fault is that?

Again, I'm not claiming the packet is broken; I'm agreeing that the gear is
broken.  The guy investigating why might wonder if the packet is sane,
or if perhaps some other part of the system is corrupting it somewhere, and
might benefit from reading the document.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 Jul 2014 17:03:55 +0200

Le 17/07/2014 17:29, Templin, Fred L a écrit :
> field.

And if there is no extension header this 'blank' would be the smallest 
possible legitimate IPv6 packet.

In constrained environments often there is need of the smallest such 
packet but still to carry some 1byte data.

Or otherwise just the smallest possible heartbeats needed in 
applications such as VPN, NAT state maintenance.

> The IPv6 input process of the destination will receive the

I think it's always worth writing an Internet Draft.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Jul 2014 22:19:40 +0000

Hi Alex,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Monday, July 21, 2014 8:04 AM
> To: [email-masked]
> Subject: Re: blanks
> 

Right.

> applications such as VPN, NAT state maintenance.

Small heartbeats is certainly one of the "why's" I was referring to.
 
> I think it's always worth writing an Internet Draft.

I'm still not sure. Again, I would prefer a draft that focuses
on "why" instead of "how".

Thanks - Fred