Subject: [Int-area] Draft Review Request - IPv4 Options Classes Registry

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 27 Nov 2010 14:17:16 +0200

Hello all,

Can I ask you to review the document, which I have recently made?
The link to it is given below.

Thank you very much for your time.

All the best,
Mykyta Yevstifeyev

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : IANA Registry for IPv4 Options Classes
> 	Author(s)       : M. Yevstifeyev
> 	Filename        : draft-yevstifeyev-ipv4-options-classes-registry-01.txt
> 	Pages           : 4
> 	Date            : 2010-11-16
>
> This document creates a registry for IPv4 options classes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yevstifeyev-ipv4-options-classes-registry-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-ipv4-options-classes-registry-01.txt>
>

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 29 Nov 2010 20:48:55 +0000

A simple comment – your problem statement needs work. There are lots of existing protocol definitions that would require updating an RFC to change them – that’s business as usual.

Why is it a problem that you need to update RFC 791 in order to create a new class of IPv4 options?
Specifically – do you have even anecdotal evidence that this has prevented developers from defining a new IPv4 options class in the past or otherwise presented a problem for potential IPv4 options implementations? For that matter, can you point to any IPv4 options that are in wide use today to show why it’s relevant to make it easier to define new ones? I know my routers are configured to ignore IP options, and I’m pretty sure that’s considered BCP at least for transit routers.

Lastly – isn’t this a little bit of “rearranging deck chairs on the Titanic?” The IANA IPv4 free pool is less than 3 months away from exhaustion. I’d rather developers concentrate on making their applications IPv6-capable and enable new knobs within the context of the IPv6 header than to make it easier to build new knobs in the IPv4 header.

Unless you have a practical application that would benefit from this change, I am not sure I see why this is something we should expend energy on.

Thanks,
Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mykyta Yevstifeyev
Sent: Saturday, November 27, 2010 7:17 AM
To: [email-masked]
Subject: [Int-area] Draft Review Request - IPv4 Options Classes Registry

Hello all,

All the best,
Mykyta Yevstifeyev

________________________________

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 30 Nov 2010 12:47:58 +0200

> Why is it a problem that you need to update RFC 791 in order to create a new class of IPv4 options?
There is no problem. There is my draft defining a new option class for IPv4:

https://datatracker.ietf.org/doc/draft-yevstifeyev-ipv4-options-class-informational/

which updates RFC 791 (if approved)
> Specifically – do you have even anecdotal evidence that this has prevented developers from defining a new IPv4 options class in the past or otherwise presented a problem for potential IPv4 options implementations?
However during long history of IPv4 no attempts to create a new option 
class have been made, as I know.
>   For that matter, can you point to any IPv4 options that are in wide use today to show why it’s relevant to make it easier to define new ones? I know my routers are configured to ignore IP options, and I’m pretty sure that’s considered BCP at least for transit routers.
>
> Lastly – isn’t this a little bit of “rearranging deck chairs on the Titanic?” The IANA IPv4 free pool is less than 3 months away from exhaustion.
For this, I think a solution for this problem is defining a new option, 
which will provide a possibility to extend the options pool.
This option would be like:

+-----------+-----------+-----------+-----------//-----------+
|    Type       | Length       | Ex. type    | Opt.-spec. data            |
+-----------+-----------+-----------+-----------//-----------+

Where Ex. type is Extended type. In this way we'll add more 255 option 
numbers, which. IMO, won't be exhausted during
at least 2 decades.
>   I’d rather developers concentrate on making their applications IPv6-capable and enable new knobs within the context of the IPv6 header than to make it easier to build new knobs in the IPv4 header.
IPv4 is still in use and even more widely-used than IPv6
All the best,
Mykyta Yevstifeyev

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 30 Nov 2010 14:21:52 +0000

> -----Original Message-----
> From: Mykyta Yevstifeyev [mailto:[email-masked]]
> Sent: Tuesday, November 30, 2010 5:48 AM
> To: George, Wes E [NTK]
> Cc: [email-masked]
> Subject: Re: [Int-area] Draft Review Request - IPv4 Options Classes
> Registry
>

[WES] Ok, and why do we need this new option class? Your justification in the above draft appears to be a semantic one - where certain implementations use debugging and measurement while not technically being either. What is the issue with this other than it being semantically incorrect? Practical application, please. Explanation of why this breaks things, please. For that matter, what about the existing implementations that are apparently incorrect? Are you expecting them to be updated to use the new option? I wouldn't...

> > Lastly – isn’t this a little bit of “rearranging deck chairs on the
> Titanic?” The IANA IPv4 free pool is less than 3 months away from
> exhaustion.

> ... In this way we'll add more 255 option
[WES] You're rather completely missing my point, I think. This isn't about exhausting the IPv4 *options*. This is about exhausting the IPv4 *addresses*. It doesn't matter that we have all of these new options values if we can't use IPv4 because operators and businesses can't get any more IPv4 addresses from the RIRs.

Thanks
Wes George

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 30 Nov 2010 17:37:20 +0200

George,

A few notes:

> [WES] Ok, and why do we need this new option class? Your justification in the above draft appears to be a semantic one - where certain implementations use debugging and measurement while not techni…
I have a few ideas for the options to be assigned to 'Informational', 
but there is no such class and there is no way to make even a draft 
while having no class. There are no any practical examples of using *not 
existing* class. How can a specification of IPv4 option for *not 
existing* class *exist*?
> [WES] You're rather completely missing my point, I think. This isn't about exhausting the IPv4 *options*. This is about exhausting the IPv4 *addresses*.
Yes, here a agree. I thought you mean IPv4 options.
>   It doesn't matter that we have all of these new options values if we can't use IPv4 because operators and businesses can't get any more IPv4 addresses from the RIRs.
>
> Thanks
> Wes George
>
Mykyta Yevstifeyev

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 30 Nov 2010 18:26:51 +0000

> Sent: Tuesday, November 30, 2010 10:37 AM
> To: George, Wes E [NTK]
> Cc: [email-masked]

> > [WES] Ok, and why do we need this new option class? Your
> justification in the above draft appears to be a semantic one - where
> certain implementations use debugging and measurement while not
> technically being either. What is the issue with this other than it
> being semantically incorrect? Practical application, please.
> Explanation of why this breaks things, please. For that matter, what
> about the existing implementations that are apparently incorrect? Are
> you expecting them to be updated to use the new option? I wouldn't...

> existing* class. How can a specification of IPv4 option for *not

[WES] Let me clarify what I mean. This is about answering the question, "what 
technical problem does having additional option classes solve?" So when I say 
practical application, I'm looking for an example of some application of IP 
Options in use today that could have been made better if this hypothetical 
class existed, and why it would have been better. Or, a hypothetical 
application that is broken by today's standard and would need your proposed 
draft to fix it. In other words, if you have ideas as to how this might be 
used, not simply the options to be assigned to your new class, you need to 
make that clear, or else this just looks like a draft for the sake of writing 
a draft.

Thanks
Wes George

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2010 10:55:58 -0800

If I understand this correctly:

RFC791 has 4 option classes already defined

you want to move that info to an IANA registry, so that the values can 
be reassigned/redefined without updating RFC791

to do this, your doc would need to update RFC791 now

----

Since nobody has ever asked for this capability, it's not clear why it's 
useful to change RFC 791 now in the hope of not changing it in the future.

I.e., this seems to avoid repeatedly blowing up the house by blowing up 
the house. I don't see that as productive.

It's sufficient to assume that, IF we ever are asked for such a change, 
we can decide IN THAT DOC whether to just make a single change or create 
a registry then.

Joe

On 11/27/2010 4:17 AM, Mykyta Yevstifeyev wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2010 11:06:12 -0800

On 11/30/2010 7:37 AM, Mykyta Yevstifeyev wrote:
...
> I have a few ideas for the options to be assigned to 'Informational',

That seems to be already covered under "debugging and measurement". If 
you believe otherwise, it'd be useful to explain what you envision this 
new class to be and why it is important (especially since the use of 
options is basically nonexistent, since they use the slow-path of most 
routers)

> while having no class.

There is a way - write a draft that argues for the creation of a new 
class (using one of the reserved ones), and include in that argument the 
new option(s) you want to propose.

 > There are no any practical examples of using *not

A better question is "what are you doing that is neither control nor 
debugging/measurement"?

JOe