[sunset4] Declaring IPv4 Historic

[Lee Howard]

As noted below, I¹ve posted a draft. I thought I¹d start a thread for
discussing it.

PLEASE Please please read the draft before commenting. It¹s very short, less
than 500 words, and I anticipate a lot of people having strong feelings
about it. I would really rather not waste time arguing about things it
doesn¹t say.

To that end, I¹ve also written a blog post, explaining in a level of detail
I thought inappropriate for the draft:
http://www.wleecoyote.com/blog/ipv4-historic.htm

Thank you,

Lee

From: sunset4 <sunset4-***@ietf.org> on behalf of Wesley George
<***@twcable.com>
Date: Monday, March 14, 2016 at 6:28 PM
To: "***@ietf.org" <***@ietf.org>
Subject: [sunset4] Agenda items?

> As you can see, we have a meeting scheduled for BA.
> As of right now, we have a single agenda item:
>
> https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00
>
> While I fully expect that this item can expand to fill all available time, if
> there are other things that the WG wishes to discuss, please respond ASAP to
> request agenda time.
>
> Thanks,
>
> Wes
>
> Anything below this line has been added by my company¹s mail server, I have no
> control over it.
> -----------
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.
> _______________________________________________ sunset4 mailing list
> ***@ietf.org https://www.ietf.org/mailman/listinfo/sunset4

[Marc Blanchet]

On 15 Mar 2016, at 3:09, Lee Howard wrote:

> As noted below, I¹ve posted a draft. I thought I¹d start a thread
> for
> discussing it.

starting the discussion ;-)
- courageous you are.

«  The IETF does not update Historic RFCs. Therefore, the IETF will
no
longer work on IPv4 technologies, including transition
technologies. »

I think this needs clarification. For example:
- what does that mean for current protocols specifications that are
already dual-stacked, when they are updated? If there is a field with
IPv4 address in the update specification, what does that really mean?
It might just break the protocol if we avoid the IPv4 address in the
update. SIP/WebRTC comes to mind

- transition technologies. you meant I guess IPv4 to IPv6 transition
technologies. Might be good to be more explicit.
- transition technologies: there are a few that are « helping » IPv6
deployment, one in mind is NAT64/DNS64. Does this mean we can not work
on augmenting/making NAT64/DNS64 better?

Marc.

>
> PLEASE Please please read the draft before commenting. It¹s very
> short, less
> than 500 words, and I anticipate a lot of people having strong
> feelings
> about it. I would really rather not waste time arguing about things it
> doesn¹t say.
>
> To that end, I¹ve also written a blog post, explaining in a level of
> detail
> I thought inappropriate for the draft:
> http://www.wleecoyote.com/blog/ipv4-historic.htm
>
> Thank you,
>
> Lee
>
> From: sunset4 <sunset4-***@ietf.org> on behalf of Wesley George
> <***@twcable.com>
> Date: Monday, March 14, 2016 at 6:28 PM
> To: "***@ietf.org" <***@ietf.org>
> Subject: [sunset4] Agenda items?
>
>> As you can see, we have a meeting scheduled for BA.
>> As of right now, we have a single agenda item:
>>
>> https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00
>>
>> While I fully expect that this item can expand to fill all available
>> time, if
>> there are other things that the WG wishes to discuss, please respond
>> ASAP to
>> request agenda time.
>>
>> Thanks,
>>
>> Wes
>>
>> Anything below this line has been added by my company¹s mail server,
>> I have no
>> control over it.
>> -----------
>>
>>
>>
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or
>> subject to
>> copyright belonging to Time Warner Cable. This E-mail is intended
>> solely for
>> the use of the individual or entity to which it is addressed. If you
>> are not
>> the intended recipient of this E-mail, you are hereby notified that
>> any
>> dissemination, distribution, copying, or action taken in relation to
>> the
>> contents of and attachments to this E-mail is strictly prohibited and
>> may be
>> unlawful. If you have received this E-mail in error, please notify
>> the sender
>> immediately and permanently delete the original and any copy of this
>> E-mail
>> and any printout.
>> _______________________________________________ sunset4 mailing list
>> ***@ietf.org https://www.ietf.org/mailman/listinfo/sunset4
>
>
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4

[Alejandro Acosta]

Hi Lee,
I read both, your blog post and your draft.
I believe this is a quite interesting idea, actually I support it but
my suggestion is to make (the whole draft) it more "IPv4 core" centric.
I mean, for example:

"The IETF does not update Historic RFCs. Therefore, the IETF will no
longer work on IPv4 technologies, including transition technologies.
"

I would remove transition technologies, also, as suggested by Marc,
more context around this text would be a good idea.

Regards,

Alejandro,


El 3/15/2016 a las 2:39 AM, Lee Howard escribió:
> As noted below, I’ve posted a draft. I thought I’d start a thread for
> discussing it.
>
> PLEASE Please please read the draft before commenting. It’s very
> short, less than 500 words, and I anticipate a lot of people having
> strong feelings about it. I would really rather not waste time arguing
> about things it doesn’t say.
>
> To that end, I’ve also written a blog post, explaining in a level of
> detail I thought inappropriate for the
> draft: http://www.wleecoyote.com/blog/ipv4-historic.htm
>
> Thank you,
>
> Lee
>
> From: sunset4 <sunset4-***@ietf.org
> <mailto:sunset4-***@ietf.org>> on behalf of Wesley George
> <***@twcable.com <mailto:***@twcable.com>>
> Date: Monday, March 14, 2016 at 6:28 PM
> To: "***@ietf.org <mailto:***@ietf.org>" <***@ietf.org
> <mailto:***@ietf.org>>
> Subject: [sunset4] Agenda items?
>
> As you can see, we have a meeting scheduled for BA.
> As of right now, we have a single agenda item:
>
> https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00
>
> While I fully expect that this item can expand to fill all
> available time, if there are other things that the WG wishes to
> discuss, please respond ASAP to request agenda time.
>
> Thanks,
>
>
>
> Wes
>
>
>
> Anything below this line has been added by my company’s mail
> server, I have no control over it.
>
> -----------
>
>
> ------------------------------------------------------------------------
>
> This E-mail and any of its attachments may contain Time Warner
> Cable proprietary information, which is privileged, confidential,
> or subject to copyright belonging to Time Warner Cable. This
> E-mail is intended solely for the use of the individual or entity
> to which it is addressed. If you are not the intended recipient of
> this E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents
> of and attachments to this E-mail is strictly prohibited and may
> be unlawful. If you have received this E-mail in error, please
> notify the sender immediately and permanently delete the original
> and any copy of this E-mail and any printout.
> _______________________________________________ sunset4 mailing
> list ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/sunset4
>
>
>
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4

[Jacques Latour]

Lee,

It's the right thing to do to set a stake in the ground and stop developing new standards that rely on IPv4. Why not now? +1

I think your draft is more appropriate at this time than the one we were working on to shutdown IPv4 on a specific date (https://github.com/jacqueslatour/Shutdown-IPv4)

Jacques




From: sunset4 [mailto:sunset4-***@ietf.org] On Behalf Of Alejandro Acosta
Sent: March-15-16 1:16 PM
To: ***@ietf.org
Subject: Re: [sunset4] Declaring IPv4 Historic

Hi Lee,
I read both, your blog post and your draft.
I believe this is a quite interesting idea, actually I support it but my suggestion is to make (the whole draft) it more "IPv4 core" centric.
I mean, for example:

"The IETF does not update Historic RFCs. Therefore, the IETF will no
longer work on IPv4 technologies, including transition technologies.
"

I would remove transition technologies, also, as suggested by Marc, more context around this text would be a good idea.

Regards,

Alejandro,


El 3/15/2016 a las 2:39 AM, Lee Howard escribió:
As noted below, I've posted a draft. I thought I'd start a thread for discussing it.

PLEASE Please please read the draft before commenting. It's very short, less than 500 words, and I anticipate a lot of people having strong feelings about it. I would really rather not waste time arguing about things it doesn't say.

To that end, I've also written a blog post, explaining in a level of detail I thought inappropriate for the draft: http://www.wleecoyote.com/blog/ipv4-historic.htm

Thank you,

Lee

From: sunset4 <sunset4-***@ietf.org<mailto:sunset4-***@ietf.org>> on behalf of Wesley George <***@twcable.com<mailto:***@twcable.com>>
Date: Monday, March 14, 2016 at 6:28 PM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: [sunset4] Agenda items?

As you can see, we have a meeting scheduled for BA.
As of right now, we have a single agenda item:

https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00

While I fully expect that this item can expand to fill all available time, if there are other things that the WG wishes to discuss, please respond ASAP to request agenda time.

Thanks,

Wes

Anything below this line has been added by my company's mail server, I have no control over it.
-----------

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________ sunset4 mailing list ***@ietf.org<mailto:***@ietf.org> https://www.ietf.org/mailman/listinfo/sunset4




_______________________________________________

sunset4 mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/sunset4

[joel jaeggli]

On 3/15/16 10:15 AM, Alejandro Acosta wrote:
> Hi Lee,
> I read both, your blog post and your draft.
> I believe this is a quite interesting idea, actually I support it but
> my suggestion is to make (the whole draft) it more "IPv4 core" centric.
> I mean, for example:
>
> "The IETF does not update Historic RFCs. Therefore, the IETF will no
> longer work on IPv4 technologies, including transition technologies.
> "
>
> I would remove transition technologies, also, as suggested by Marc,
> more context around this text would be a good idea.

I have demonstrably less interest in transition technologies then I do
in the continued function operation and maintenance of legacy ipv4 until
such time as I not longer need it. which is not to say that transition
technologies don't have glaring issues. many of them do.

> Regards,
>
> Alejandro,
>
>
> El 3/15/2016 a las 2:39 AM, Lee Howard escribió:
>> As noted below, I’ve posted a draft. I thought I’d start a thread for
>> discussing it.
>>
>> PLEASE Please please read the draft before commenting. It’s very
>> short, less than 500 words, and I anticipate a lot of people having
>> strong feelings about it. I would really rather not waste time arguing
>> about things it doesn’t say.
>>
>> To that end, I’ve also written a blog post, explaining in a level of
>> detail I thought inappropriate for the
>> draft: <http://www.wleecoyote.com/blog/ipv4-historic.htm>http://www.wleecoyote.com/blog/ipv4-historic.htm
>>
>> Thank you,
>>
>> Lee
>>
>> From: sunset4
>> <<mailto:sunset4-***@ietf.org>sunset4-***@ietf.org> on behalf
>> of Wesley George <***@twcable.com
>> <mailto:***@twcable.com>>
>> Date: Monday, March 14, 2016 at 6:28 PM
>> To: "<mailto:***@ietf.org>***@ietf.org" <***@ietf.org
>> <mailto:***@ietf.org>>
>> Subject: [sunset4] Agenda items?
>>
>> As you can see, we have a meeting scheduled for BA.
>> As of right now, we have a single agenda item:
>>
>> https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00
>>
>> While I fully expect that this item can expand to fill all
>> available time, if there are other things that the WG wishes to
>> discuss, please respond ASAP to request agenda time.
>>
>> Thanks,
>>
>>
>>
>> Wes
>>
>>
>>
>> Anything below this line has been added by my company’s mail
>> server, I have no control over it.
>>
>> -----------
>>
>>
>> ------------------------------------------------------------------------
>>
>> This E-mail and any of its attachments may contain Time Warner
>> Cable proprietary information, which is privileged, confidential,
>> or subject to copyright belonging to Time Warner Cable. This
>> E-mail is intended solely for the use of the individual or entity
>> to which it is addressed. If you are not the intended recipient of
>> this E-mail, you are hereby notified that any dissemination,
>> distribution, copying, or action taken in relation to the contents
>> of and attachments to this E-mail is strictly prohibited and may
>> be unlawful. If you have received this E-mail in error, please
>> notify the sender immediately and permanently delete the original
>> and any copy of this E-mail and any printout.
>> _______________________________________________ sunset4 mailing
>> list ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sunset4
>>
>>
>>
>> _______________________________________________
>> sunset4 mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/sunset4
>
>
>
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>

[Ted Lemon]

When was the last document published that updated one of the IPv4 specifications?

Are we counting routing drafts?

[Lee Howard]

(I do not intend to reply to every message; I would rather hear opinions,
and occasionally summarize points for discuss or check consensus on
individual points; but answering questions is different)

On 3/15/16, 6:26 PM, "Ted Lemon" <***@nominum.com> wrote:

>When was the last document published that updated one of the IPv4
>specifications?
>
>Are we counting routing drafts?


https://www.rfc-editor.org/info/rfc791 says that rfc791 has been updated
three times:

RFC 1349 <https://www.rfc-editor.org/info/rfc1349>, Type of Service in the
Internet Protocol Suite, 1992.
RFC 2474 <https://www.rfc-editor.org/info/rfc2474>, Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,
1998.
RFC 6864 <https://www.rfc-editor.org/info/rfc6864>, Updated Specification
of the IPv4 ID Field, 2013.


I would argue that if a case like any of those happened today, it would be
fine to update IPv6 and leave IPv4 as it is.

Lee

[Ted Lemon]

> >Are we counting routing drafts?
> https://www.rfc-editor.org/info/rfc791 says that rfc791 has been updated
three times:

So, "no"? :)

Ah, I should have read more carefully--you do say explicitly that you are just talking about RFC 791.

I don't really see the point of this, but I don't have a specific objection, either.

[joel jaeggli]

On 3/15/16 10:26 AM, Ted Lemon wrote:
> When was the last document published that updated one of the IPv4 specifications?

I didn't look very hard, but 6864 updates RFC 791, RFC 2003, RFC 1122

> Are we counting routing drafts?
>
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>

[Fred Baker (fred)]

> On Mar 15, 2016, at 10:26 AM, Ted Lemon <***@nominum.com> wrote:
>
> When was the last document published that updated one of the IPv4 specifications?
>
> Are we counting routing drafts?

By "one of the IPv4 specifications" do you mean RFC 791, or "a specification using IPv4"?

If you mean "updates 791", That was February 2013:
https://tools.ietf.org/html/rfc0791
0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349, RFC2474, RFC6864)
(Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0791)

https://tools.ietf.org/html/rfc6864
6864 Updated Specification of the IPv4 ID Field. J. Touch. February 2013.
(Format: TXT=44418 bytes) (Updates RFC0791, RFC1122, RFC2003)
(Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6864)

If you mean "a specification using IPv4", that would have been in January 2016:

https://tools.ietf.org/html/rfc6826
6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., T.
Eckert, N. Leymann, M. Napierala. January 2013. (Format: TXT=23927
bytes) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC6826)

https://tools.ietf.org/html/rfc7246
7246 Multipoint Label Distribution Protocol In-Band Signaling in a
Virtual Routing and Forwarding (VRF) Table Context. IJ. Wijnands,
Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura.
June 2014. (Format: TXT=24698 bytes) (Updated by RFC7438) (Status:
PROPOSED STANDARD) (DOI: 10.17487/RFC7246)

https://tools.ietf.org/html/rfc7438
7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards. IJ.
Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura. January
2015. (Format: TXT=36744 bytes) (Updates RFC6826, RFC7246) (Status:
PROPOSED STANDARD) (DOI: 10.17487/RFC7438)

[RFC6826] and [RFC7246] define the following Opaque Value TLVs:
Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4
Source TLV, and Transit VPNv6 Source TLV. The value field of each
such TLV is divided into a number of subfields, one of which contains
an IP source address, and one of which contains an IP group address.
Per those documents, these fields must contain valid IP addresses.

Procedures for the use of a wildcard group in the following TLVs
(defined in [RFC6826] or [RFC7246]) are outside the scope of the
current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV,
Transit VPNv4 Bidir TLV, and Transit VPNv6 Bidir TLV.

[George, Wes]

On 3/15/16, 12:47 PM, "sunset4 on behalf of Philip Homburg"
<sunset4-***@ietf.org on behalf of pch-***@u-1.phicoh.com> wrote:

>If you can't develop new
>standards that involve the protocol that carries more than 50% of the
>world
>internet traffic, then you are doing something wrong.

</chair hat>
WG] I don't think that's what this draft is suggesting. The vast majority
of IETF standards are wholly agnostic to the version number in the IP
packet, and as such will continue regardless of whether IPv4 is declared
historic. What changes is that it is no longer strictly necessary (or
permitted) to make concessions in the standard to ensure that it works
properly over the now historic IP version in cases where the IP version
matters to the protocol or standard being developed.
As an example: if I as a software developer have a program that was
originally developed to work on Windows XP, and I deprecate support for
that OS, the downrev version that I wrote before I deprecated support for
XP will keep working, and while it's possible that the new version I
optimized to run on Windows 8 and 10 might mostly still work on XP, if you
file a bug complaining that something, especially a feature that I
newly-introduced on the current version of software, doesn't work on XP,
I'll ignore you.

Additionally, consider the time scale at which IETF operates - 2-3 years
for significant deployment of new standards is usually fairly aggressive,
and this draft is going to take some time to achieve consensus, in
addition to it being dependent on IPv6 being elevated to full Standard.
I'm not convinced that by then IPv4 will still be the majority given its
current burn rate and IPv6's growth rate.

Thanks
Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

[Ca By]

On Tue, Mar 15, 2016 at 11:57 AM, George, Wes <***@twcable.com>
wrote:

>
>
> On 3/15/16, 12:47 PM, "sunset4 on behalf of Philip Homburg"
> <sunset4-***@ietf.org on behalf of pch-***@u-1.phicoh.com> wrote:
>
> >If you can't develop new
> >standards that involve the protocol that carries more than 50% of the
> >world
> >internet traffic, then you are doing something wrong.
>
> </chair hat>
> WG] I don't think that's what this draft is suggesting. The vast majority
> of IETF standards are wholly agnostic to the version number in the IP
> packet, and as such will continue regardless of whether IPv4 is declared
> historic. What changes is that it is no longer strictly necessary (or
> permitted) to make concessions in the standard to ensure that it works
> properly over the now historic IP version in cases where the IP version
> matters to the protocol or standard being developed.
> As an example: if I as a software developer have a program that was
> originally developed to work on Windows XP, and I deprecate support for
> that OS, the downrev version that I wrote before I deprecated support for
> XP will keep working, and while it's possible that the new version I
> optimized to run on Windows 8 and 10 might mostly still work on XP, if you
> file a bug complaining that something, especially a feature that I
> newly-introduced on the current version of software, doesn't work on XP,
> I'll ignore you.
>
> Additionally, consider the time scale at which IETF operates - 2-3 years
> for significant deployment of new standards is usually fairly aggressive,
> and this draft is going to take some time to achieve consensus, in
> addition to it being dependent on IPv6 being elevated to full Standard.
> I'm not convinced that by then IPv4 will still be the majority given its
> current burn rate and IPv6's growth rate.
>
> Thanks
> Wes George
>
>
+1 to Wes and the I-D being good as is. It is crisp and clear statement of
how we as the IETF are moving forward.

CB

Anything below this line has been added by my company’s mail server, I
> have no control over it.
> -----------
>
>
> ________________________________
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>

[Heatley, Nick]

+1, I agree.
Other SDOs would appreciate the clear direction the IETF would be setting by this.
Nick

From: sunset4 [mailto:sunset4-***@ietf.org] On Behalf Of Ca By
Sent: 15 March 2016 20:51
To: George, Wes
Cc: Philip Homburg; ***@ietf.org
Subject: Re: [sunset4] Declaring IPv4 Historic


+1 to Wes and the I-D being good as is. It is crisp and clear statement of how we as the IETF are moving forward.

CB

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
sunset4 mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/sunset4


NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above.
If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited.
If you've received this email in error, please let me know immediately on the email address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited
Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

[Scott Morizot]

On Tue, Mar 15, 2016 at 2:09 AM, Lee Howard <***@asgard.org> wrote:

> As noted below, I’ve posted a draft. I thought I’d start a thread for
> discussing it.
>
> PLEASE Please please read the draft before commenting. It’s very short,
> less than 500 words, and I anticipate a lot of people having strong
> feelings about it. I would really rather not waste time arguing about
> things it doesn’t say.
>
>
+1

I've read the draft and your blog post and it does seem like the
appropriate and logical next step.

Scott

[Fred Baker (fred)]

> On Mar 16, 2016, at 6:36 AM, Scott Morizot <***@gmail.com> wrote:
>
> I've read the draft and your blog post and it does seem like the appropriate and logical next step.

++

[Tassos Chatzithomaoglou]

I support the idea of this draft, but...
> The IETF does not update Historic RFCs. Therefore, the IETF will no
> longer work on IPv4 technologies, including transition technologies.
...i would like to see included some clarifications about the transition technologies.
It seems risky to "abandon" softwires/behave work without having good exposure on operators.
It's like we assume that everything transition-related will either work fine or won't be needed.

Also i would to have more information about the draft's effect on DHCP and any new options may come out.

--
Tassos

Lee Howard wrote on 15/3/16 09:09:
> As noted below, I’ve posted a draft. I thought I’d start a thread for discussing it.
>
> PLEASE Please please read the draft before commenting. It’s very short, less than 500 words, and I anticipate a lot of people having strong feelings about it. I would really rather not waste time arguing about things it doesn’t say.
>
> To that end, I’ve also written a blog post, explaining in a level of detail I thought inappropriate for the draft: http://www.wleecoyote.com/blog/ipv4-historic.htm
>
> Thank you,
>
> Lee
>
> From: sunset4 <sunset4-***@ietf.org <mailto:sunset4-***@ietf.org>> on behalf of Wesley George <***@twcable.com <mailto:***@twcable.com>>
> Date: Monday, March 14, 2016 at 6:28 PM
> To: "***@ietf.org <mailto:***@ietf.org>" <***@ietf.org <mailto:***@ietf.org>>
> Subject: [sunset4] Agenda items?
>
> As you can see, we have a meeting scheduled for BA.
> As of right now, we have a single agenda item:
>
> https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00
>
> While I fully expect that this item can expand to fill all available time, if there are other things that the WG wishes to discuss, please respond ASAP to request agenda time.
>
> Thanks,
>
>
>
> Wes
>
>
>
> Anything below this line has been added by my company’s mail server, I have no control over it.
>
> -----------
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________ sunset4 mailing list ***@ietf.org <mailto:***@ietf.org> https://www.ietf.org/mailman/listinfo/sunset4
>
>
>
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4

[Lee Howard]

On 3/16/16, 7:26 PM, "sunset4 on behalf of Tassos Chatzithomaoglou"
<sunset4-***@ietf.org on behalf of ***@forthnet.gr> wrote:

>I support the idea of this draft, but...
>> The IETF does not update Historic RFCs. Therefore, the IETF will no
>> longer work on IPv4 technologies, including transition technologies.
>...i would like to see included some clarifications about the transition
>technologies.
>It seems risky to "abandon" softwires/behave work without having good
>exposure on operators.
>It's like we assume that everything transition-related will either work
>fine or won't be needed.

This is one of the most common comments I¹ve gotten so far. I do think
there¹s operational experience with all of the major transition
technologies, but they¹re all still fairly new.

What would folks think of modifying the statement from:
the IETF will no
longer work on IPv4 technologies, including transition technologies.


To:
the IETF will no
longer develop new IPv4 technologies, including IPv4-IPv6 transition
technologies.

I¹d like to get across the idea that new development will be in IPv6, not
IPv4. The IPv4 spec itself won¹t be updated at all (once it¹s Historic),
but transition technologies could be revised for operational and security
reasons. Also, I feel pretty strongly (but will listen to consensus) that
it¹s too late to develop any new transition (or life-extension)
technologies.

>
>Also i would to have more information about the draft's effect on DHCP
>and any new options may come out.

What would you like it to say?
Can we stop it with new DHCP (v4) options, and just put them in IPv6? Do
we need to list all IPv4-specific protocols and technologies and specify
whether they can be revised?



>
>--
>Tassos

Thanks,

Lee

[Tassos Chatzithomaoglou]

>> Also i would to have more information about the draft's effect on DHCP
>> and any new options may come out.
> What would you like it to say?
> Can we stop it with new DHCP (v4) options, and just put them in IPv6? Do
> we need to list all IPv4-specific protocols and technologies and specify
> whether they can be revised?
>
>
>
I consider DHCPv4 one of the most-used protocols that will stay for a long time with us, because it's not directly affected by what happens on the global internet.
I can even imagine whole "islands" staying on IPv4 and using it for many decades.
Assuming IPv4 is declared as historic, does this mean that no other options are expected to be defined for DHCP?
Do we assume that any new applications won't need those?

Maybe a note should be added about the exclusion of creating new options for such cases. So the actual protocol standard won't see any development, but protocol "extensions" through standard-defined options may happen.


--
Tassos

[Scott Morizot]

On Mar 17, 2016 12:09, "Tassos Chatzithomaoglou" <***@forthnet.gr> wrote:
> I consider DHCPv4 one of the most-used protocols that will stay for a
long time with us, because it's not directly affected by what happens on
the global internet.

And, as with IPv4 itself, declaring v4 historic does nothing to prevent
people from using dhcpv4 as long as they require it. It simply means the
IETF will no longer work on the protocol. DHCP already includes a way to
define custom options if users of the historic IPv4 protocol decide to
define and use a new option. I'm not sure I see a need for the standards
body to spend time on it.

No strong objection either if it's something enough people want to spend
time and energy doing, but since DHCPv4 is tightly coupled with IPv4, it
seems reasonable that it be considered historic as well.

> I can even imagine whole "islands" staying on IPv4 and using it for many
decades.

>From an enterprise perspective that seems incredibly foolish. It's actually
at the edge that v4 is required for the long haul. Having begun the
transition, the sooner most of our enterprise is on one protocol again the
better.

> Assuming IPv4 is declared as historic, does this mean that no other
options are expected to be defined for DHCP?

For DHCPv4, that seems reasonable. New work should focus on DHCPv6, which
is a pretty different protocol. But again, I don't feel particularly
strongly either way.

> Do we assume that any new applications won't need those?

Part of making v4 historic means that the IETF is only committed to
ensuring new protocols work with v6, at least if I've understood the
definition correctly. New stuff might still work over v4, but it becomes a
case of caveat emptor.

> Maybe a note should be added about the exclusion of creating new options
for such cases. So the actual protocol standard won't see any development,
but protocol "extensions" through standard-defined options may happen.

It is an interesting question how a protocol that's as tightly coupled with
IPv4 as DHCPv4 is impacted by making IPv4 historic. I don't recall seeing
anything that directly addressed that question.

Scott

[Marc Blanchet]

On 17 Mar 2016, at 6:35, Lee Howard wrote:

> On 3/16/16, 7:26 PM, "sunset4 on behalf of Tassos Chatzithomaoglou"
> <sunset4-***@ietf.org on behalf of ***@forthnet.gr> wrote:
>
>> I support the idea of this draft, but...
>>> The IETF does not update Historic RFCs. Therefore, the IETF will
>>> no
>>> longer work on IPv4 technologies, including transition
>>> technologies.
>> ...i would like to see included some clarifications about the
>> transition
>> technologies.
>> It seems risky to "abandon" softwires/behave work without having good
>> exposure on operators.
>> It's like we assume that everything transition-related will either
>> work
>> fine or won't be needed.
>
> This is one of the most common comments I¹ve gotten so far. I do
> think
> there¹s operational experience with all of the major transition
> technologies, but they¹re all still fairly new.
>
> What would folks think of modifying the statement from:
> the IETF will no
> longer work on IPv4 technologies, including transition
> technologies.
>
>
> To:
> the IETF will no
> longer develop new IPv4 technologies, including IPv4-IPv6
> transition
> technologies.

I like it better. I would suggest « including IPv4 to IPv6 transition
technologies. (to avoid excluding NAT64 and related that are needed for
the next decade


>
> I¹d like to get across the idea that new development will be in IPv6,
> not
> IPv4. The IPv4 spec itself won¹t be updated at all (once it¹s
> Historic),
> but transition technologies could be revised for operational and
> security
> reasons. Also, I feel pretty strongly (but will listen to consensus)
> that
> it¹s too late to develop any new transition (or life-extension)
> technologies.

I agree, except for v6 to v4 such as NAT64.

Marc.

>
>>
>> Also i would to have more information about the draft's effect on
>> DHCP
>> and any new options may come out.
>
> What would you like it to say?
> Can we stop it with new DHCP (v4) options, and just put them in IPv6?
> Do
> we need to list all IPv4-specific protocols and technologies and
> specify
> whether they can be revised?
>
>
>
>>
>> --
>> Tassos
>
> Thanks,
>
> Lee
>
>
>
> _______________________________________________
> sunset4 mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4

[Greg Skinner]

It occurred to me that there might be some people who have an active interest in updating the IPv4
standard in the not too distant future, such as those who want to use 240.0.0.0/4.

Has an Historic RFC ever been put back on the standards track?  Is there even a process for doing that?  (I couldn't find one offhand.)  If the IPv4 standard was reclassified as Historic, and there was some desire from an active group to update it, that could become a big mess.

Greg

On Mar 15, 2016, at 05:09 AM, Lee Howard <***@asgard.org> wrote:

As noted below, I’ve posted a draft. I thought I’d start a thread for discussing it.

PLEASE Please please read the draft before commenting. It’s very short, less than 500 words, and I anticipate a lot of people having strong feelings about it. I would really rather not waste time arguing about things it doesn’t say.

To that end, I’ve also written a blog post, explaining in a level of detail I thought inappropriate for the draft: http://www.wleecoyote.com/blog/ipv4-historic.htm

Thank you,

Lee

From: sunset4 <sunset4-***@ietf.org> on behalf of Wesley George <***@twcable.com>
Date: Monday, March 14, 2016 at 6:28 PM
To: "***@ietf.org" <***@ietf.org>
Subject: [sunset4] Agenda items?

As you can see, we have a meeting scheduled for BA. 
As of right now, we have a single agenda item:

https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00

While I fully expect that this item can expand to fill all available time, if there are other things that the WG wishes to discuss, please respond ASAP to request agenda time. 

Thanks,
 
Wes
 
Anything below this line has been added by my company’s mail server, I have no control over it.

[George, Wes]

From: sunset4 <sunset4-***@ietf.org<mailto:sunset4-***@ietf.org>> on behalf of Greg Skinner <***@icloud.com<mailto:***@icloud.com>>
Date: Monday, March 21, 2016 at 9:09 PM

It occurred to me that there might be some people who have an active interest in updating the IPv4
standard in the not too distant future, such as those who want to use 240.0.0.0/4<http://www.gossamer-threads.com/lists/nanog/users/181046>.

WG] I'd argue that they've missed their window, repeatedly. This comes up [1] every [2] few [3] years [4]. It keeps failing to gain enough momentum to go anywhere, for one primary reason: a large number of IP stacks have hard-coded rules that disallow or otherwise treat 240/4 as invalid IP space, so interfaces can't be configured with it, or will drop packets they see with those addresses in the src/dst field. Even if we changed the records tomorrow, there would be significant code and configuration work necessary to enable it for any use on most platforms, punch holes in firewalls, martian lists, etc. The same reason that it's been difficult to get broader IPv6 deployment (it's expensive and time-consuming to update legacy hardware and software and get to ubiquitous enough deployment to make it broadly useful) is the same thing that limits doing anything with Class E space today. In other words, if people are willing to put in time to make changes to an IP stack, especially on older gear, that's time better spent enabling the current protocol version, rather than delaying the inevitable. The further out on the IPv6 deployment curve we get, the less sense doing something with 240/4 makes.


Has an Historic RFC ever been put back on the standards track? Is there even a process for doing that? (I couldn't find one offhand.) If the IPv4 standard was reclassified as Historic, and there was some desire from an active group to update it, that could become a big mess.

WG] There probably isn't one, because declaring a standards document historic is done via consensus just like declaring a document a standard. If there are groups that desire to update IPv4, their opportunity to express that desire is while this document is being discussed and gaining consensus to proceed. That's part of the reason this discussion is happening - it's looking for rough consensus from the IETF that we are done making changes to IPv4. If there are a few changes identified that need to be made prior to IPv4 being declared historic, I don't think that's necessarily a problem, but I think it's time for those to be identified and completed, rather than holding this out indefinitely on the change that someone might need to do something in the future.
Additionally, the IETF is not the protocol police; adhering to the standards that we generate is wholly voluntary. If a group, business, individual wishes to use 240/4 for an off–label use, and is able to convince the vendors in their particular implementation to modify the stack so that they can do so, IPv4 moving to historic status does not impact their ability to do this, any more than it impacts their ability to continue using the rest of IPv4 indefinitely.

Thanks,

Wes

[1] https://tools.ietf.org/html/draft-fuller-240space-02
[2] http://www.muada.com/drafts/draft-van-beijnum-v6ops-esiit-00.txt
[3] https://tools.ietf.org/html/draft-wilson-class-e-02
[4] http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.