Re: [sunset4] draft-tsou-stateless-nat44

["George, Wes" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Simon Perreault
> Sent: Monday, July 16, 2012 3:17 PM
> To: [e-mail]
> Subject: Re: [sunset4] draft-tsou-stateless-nat44
>
> On 07/13/2012 08:36 PM, George, Wes wrote:
> > [WEG] The chief criticism leveled at IPv4-only NAT solutions is that
> > they do nothing to encourage IPv6 deployment, and instead function as
> > IPv4 life-support by allowing carriers to delay deployment of IPv6.
> > The authors will have a significant burden of justification as to why
> > this is better than MAP in that it doesn't push the implementer to
> > deploy IPv6 on the network (or at least allow the use of IPv6 as
> > transport).
>
> You know what, I'm an optimist. I believe operators when they say they
> do want to deploy IPv6, and I believe they're doing it. I see IPv6 doing
> pretty good. It's getting deployed. I think we can fully decouple the
> problem of IPv6 deployment and residual IPv4 access. We're beyond that
> now. I don't think tying IPv6 to a residual IPv4 access protocol will
> have any impact on IPv6 adoption. It's already getting adopted quite
> nicely.
>
[WEG] I appreciate (and to some extent share) your optimism. However, there are a lot of pessimists (and a fair amount of religious fervor) hanging out in this corner of the IETF. I can point you to several thousand messages about what became RFC6598 by way of an illustration, that people still believe that IPv4 life extension is a crutch for those who are behind on IPv6 deployment, or worse, not deploying. :-) Drafts that don't have words reinforcing IPv4 extension as a temporary thing tend to perpetuate that notion, and attract those folks into delaying/opposing what may otherwise be a solid idea, simply because it prolongs the agony.
IESG's guidance has been pretty clear that it isn't acceptable to assume that IPv6 is moving along and focus on residual IPv4 as a completely separate problem. The impression I have is that they will be resistant to solutions that don't at least superficially help move the deploying network towards better IPv6 support while they solve the short-term problem with IPv4 exhaustion and legacy support.

I'm not saying "we shouldn't do this" or "we shouldn't discuss this" because it uses IPv4 transport. I'm simply noting that you have a burden of proof based on our charter and the sentiment behind it (since it was written by IESG) that you would do well to consider while writing the draft, so that you're covered well before it hits IETF last call.

Thanks
Wes George, speaking as co-chair

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.