Subject: [sunset4] Declaring IPv4 Historic

From: Lee Howard <[email-masked]>
Date: Tue, 15 Mar 2016 08:09:14 +0100

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 <[email-masked]> on behalf of Wesley George
<[email-masked]>
Date:  Monday, March 14, 2016 at 6:28 PM
To:  "[email-masked]" <[email-masked]>
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
> [email-masked] https://www.ietf.org/mailman/listinfo/sunset4

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 15 Mar 2016 08:29:51 -0400

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

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.

> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Mar 2016 17:47:44 +0100

>    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:
>    [1]http://www.wleecoyote.com/blog/ipv4-historic.htm

It seems to me that the implications of Section 3 make it that this draft 
should not be published.

I think 'It does mean that any Standards Track RFC with a Normative reference
to RFC791 is Historic.' is also problematic. 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.

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 15 Mar 2016 12:45:33 -0430

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 <[email-masked]
> <mailto:[email-masked]>> on behalf of Wesley George
> <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>     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 [email-masked] <mailto:[email-masked]>

---

From: Jacques Latour <[email-masked]>
Date: Tue, 15 Mar 2016 17:24:09 +0000

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:[email-masked]] On Behalf Of Alejandro Acosta
Sent: March-15-16 1:16 PM
To: [email-masked]
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:

  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 <[email-masked]<mailto:[email-masked]>> on behalf of Wesley George <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 14, 2016 at 6:28 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sunset4] Agenda items?

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 [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sunset4

_______________________________________________

sunset4 mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Mar 2016 17:26:58 +0000

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

Are we counting routing drafts?

---

From: Lee Howard <[email-masked]>
Date: Tue, 15 Mar 2016 13:40:24 +0100

(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)

>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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Mar 2016 18:01:07 +0000

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.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 15 Mar 2016 11:33:42 -0700

> 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

---

From: joel jaeggli <[email-masked]>
Date: Tue, 15 Mar 2016 11:34:55 -0700

> 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.

>> draft: <http://www.wleecoyote.com/blog/ipv4-historic.htm>http://www.wleecoyote.com/blog/ipv4-historic.htm
>>
>> Thank you,
>>
>> Lee
>>
>> From: sunset4
>> <<mailto:[email-masked]>[email-masked]> on behalf
>> of Wesley George <[email-masked]
>> <mailto:[email-masked]>>
>> To: "<mailto:[email-masked]>[email-masked]" <[email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Mar 2016 18:45:50 +0000

> On Mar 15, 2016, at 10:26 AM, Ted Lemon <[email-masked]> wrote:
> 

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.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 15 Mar 2016 18:57:18 +0000

On 3/15/16, 12:47 PM, "sunset4 on behalf of Philip Homburg"
<[email-masked] on behalf of [email-masked]> wrote:

>If you can't develop new

</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.
-----------

---

From: Ca By <[email-masked]>
Date: Tue, 15 Mar 2016 13:51:29 -0700

> current burn rate and IPv6's growth rate.
+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

> 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.

---

From: Scott Morizot <[email-masked]>
Date: Wed, 16 Mar 2016 08:36:32 -0500

On Tue, Mar 15, 2016 at 2:09 AM, Lee Howard <[email-masked]> wrote:

> 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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 16 Mar 2016 14:46:17 +0000

> On Mar 16, 2016, at 6:36 AM, Scott Morizot <[email-masked]> wrote:
> 
> I've read the draft and your blog post and it does seem like the appropriate and logical next step.

++

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 16 Mar 2016 20:26:29 +0200

I support the idea of this draft, but...
>    The IETF does not update Historic RFCs.  Therefore, the IETF will no
...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 <[email-masked] <mailto:[email-masked]>> on behalf of Wesley George <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Anything below this line has been added by my company’s mail server, I have no control over it.
>
>     -----------
>
>
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>     _______________________________________________ sunset4 mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sunset4 
>
>
>

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 17 Mar 2016 12:25:14 +0000

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

From: sunset4 [mailto:[email-masked]] On Behalf Of Ca By
Sent: 15 March 2016 20:51
To: George, Wes
Cc: Philip Homburg; [email-masked]
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

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

---

From: Lee Howard <[email-masked]>
Date: Thu, 17 Mar 2016 11:35:47 +0100

>It's like we assume that everything transition-related will either work

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. 

>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?

Thanks,

Lee

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Thu, 17 Mar 2016 19:08:15 +0200

> 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

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 17 Mar 2016 13:28:24 -0400

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

>> ...i would like to see included some clarifications about the 
>> transition
>> technologies.
>> It's like we assume that everything transition-related will either 
>> work
>> fine or won't be needed.
>

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…

> it¹s too late to develop any new transition (or life-extension)

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.
>

---

From: Scott Morizot <[email-masked]>
Date: Thu, 17 Mar 2016 13:10:38 -0500

On Mar 17, 2016 12:09, "Tassos Chatzithomaoglou" <[email-masked]> 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.

>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