Subject: Re: [sunset4] WG Action: sunset4 (sunset4)

From: Miya Kohno <[email-masked]>
Date: Tue, 8 May 2012 16:19:25 +0900

Hi,

I have two comments to the WG.

--------------
I. Clarification on the description.

The description says "To facilitate the graceful sunsetting of the
IPv4 Internet".

Does this mean :
 1) IETF is to promote the transition
 2) Let the market decide the transition, and IETF is to minimize the
disruption during the transition

If 1), then we should aim more for migration. The solutions which have
been coming up so far are rather for IPv4 life extension or IPv4/v6
co-existence, than for migration.

However, 2) might be more practical. The lessons we have learnt are
that we could not force nor promote the transition... And in that
case, IPv4 life extension (address sharing by NAPT44) and IPv4/v6
co-existence (Encap/Tunnel/Translation) would make sense in terms of
minimizing the disruption.

--------------
II. Scope of work

I'm afraid the works in this solution area so far tend to be scenario
development, rather than protocol/function development. The
consequence was the combinatorial explosion, wasn't it? For example,
if the element technologies are { NAPT44 | Encap/Tunnel | Translation
} and possible locations to put the functions are { host | CPE | GW@
xSP }, then it comes 2^(3+3) = 64! (Of course this didn't exclude
impossible combination, but we have more variations (e.g. port
allocation schemes for NAPT44), so it could be worse...)

So I'm wondering if this WG could simplify the works and outcomes by
sorting out the element technologies and the frameworks.

Thanks,
Miya

---

From: Tina TSOU <[email-masked]>
Date: Tue, 8 May 2012 07:25:39 +0000

Sent from my iPad

> I have two comments to the WG.
I believe this is the first milestone means.
> 
> Thanks,
> Miya
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: "George, Wes" <[email-masked]>
Date: Tue, 8 May 2012 14:45:02 -0400

I want to caveat my comments below by saying that the WG Chairs are still discussing the finer points of this charter with the ADs for some clarification, so here is my own personal opinion. Not officially a WG chair comment, but I have been privy to some discussions leading up to the formation of this WG that might help to clarify. Below inline...

> -----Original Message-----
> From: Miya Kohno [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2012 3:19 AM
> To: [email-masked]
> Cc: [email-masked]; George, Wes
> Subject: Re: [sunset4] WG Action: sunset4 (sunset4)
>
>  2) Let the market decide the transition, and IETF is to minimize the disruption
> during the transition
>
[WEG] IPv4 sunset is specifically focused on two ideas:
1) many of the protocols and implementations don't have ways to gracefully turn IPv4 completely off. They basically assume that IPv4 will always be present, even if they aren't actively using it for anything, and may consider the lack of an IPv4 address a failure condition even when it isn't. For example, SOHO routers boot, request an IPv4 address, and respond to any DHCP requests for IPv4. There's not really a way to shut that function off today, especially remotely. We are charged with identifying those things and either writing the protocol changes or generating the gap analysis so that the appropriate WG can do so. Example - a DHCPv4 option code that says "IPv4 isn't supported" or a method to signal the NAT (and/or the hosts behind it) that IPv4 can be used for local communication only (because there's no upstream IPv4 support), without resorting to simply sending TCP resets if they try to connect to something via IPv4 etc. The idea of transitioning to IPv6, whether it's feature parity issues (things missing in IPv6), or the rate of deployment is really secondary to the work this group would be doing.
2) the concept from draft-george-ipv6-support that as a protocol suite, IPv4 is functionally complete, including a set of IPv4 extension/IPv6 transition technologies that cover the majority of common use cases/problem sets. This is not declaring IPv4 historic, but rather a precursor, a "cap and grow" change. We're saying that we don't need to continue making changes and "improvements" to the protocol, and instead we need to be focusing on IPv6 or IP-version-agnostic work.

I do not think that this group could affect the rate of IPv4 -> IPv6 transition much no matter what it did. There are lots and lots and lots of documents talking the IPv4 to IPv6 transition to death, and if there is any stone unturned, that's more of a subject for 6man or v6ops. This group starts with the assumption that IPv6 critical mass is a foregone conclusion (rather than something we need to push) and that we need to focus on making it possible for people to "turn off the lights as they leave the IPv4 room." When that actually happens is not relevant, because whenever that is, we need a way to make it easier. The very act of declaring IPv4 "done" and working on graceful exit/shutdown knobs in the protocol speaks much more loudly than additional transition documents, IMO.

> consequence was the combinatorial explosion, wasn't it? For example, if the
> element technologies are { NAPT44 | Encap/Tunnel | Translation } and
> possible locations to put the functions are { host | CPE | GW@ xSP }, then it
> comes 2^(3+3) = 64! (Of course this didn't exclude impossible combination,
> but we have more variations (e.g. port allocation schemes for NAPT44), so it
> could be worse...)
>
[WEG] yes, in fact the idea is that we don't necessarily have to solve for all possible combinations, but rather we need to solve for the ones that have the most real demand. So instead of 30 solutions that are only slight variations of one another but cover all of the corner cases exactly, we maybe want to focus on nurturing 5 interoperable and widely-supported solutions that cover 90% of those corner cases, and let the other 10% work with their vendors on bespoke solutions where that makes sense. To your point above about letting the market decide, IETF can't force operators to choose one solution over another. However, there is a better likelihood that the market will coalesce if the IETF stops trying to solve for all values and focuses on more flexible solutions that fit more problem/use cases, even if this requires us to acknowledge that we're purposely leaving some work undone. However, I am not sure exactly how this group might be involved in that, other than to use the tests listed in the charter as a method to determine which things we (or the IETF itself) should be continuing to pursue.

Hopefully this is helpful...

Wes George

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.