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

From: "George, Wes" <[email-masked]>
Date: Fri, 13 Jul 2012 20:36:10 -0400

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 12:44 PM
> To: George, Wes; [email-masked]; 'Will Liu (Shucheng)'
> Subject: RE: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-
> stateless-nat44
>
> This seems to be a MAP solution.  But differs from MAP in that it uses
> an IPv4 network between the subscriber and the ISP's "stateless NAT44"
> device, whereas MAP uses an IPv6 network between the subscriber and the
> ISP's "MAP border relay" device.

[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). Also, there are already multiple competing stateless solutions. I'd rather not add another without a very good statement of what problem it's solving that the existing ones do not. That's actually the reason for question #2 - "existing technologies" also refers to alternate solutions to the same problem that are still in draft, not just existing running code.

>
> > It can also be implemented in dual-stack network(IPv4 traffic pass
> > through stateless NAT44 and IPv6 traffic pass by stateless NAT44), so
> > the network can migrate to IPv6 smoothly.
>
> Typo in that sentence?
[WEG] excepting the typo (bypass vs pass by), the draft should say this, and in fact should probably say it in stronger terms - "a network using this NAT SHOULD deploy IPv6, so that all supporting devices and content can bypass the NAT and maintain end-to-end connectivity" or some similar. This is a drum we need to beat in every draft focused on an IPv4-only solution based on the way that our charter is written and IETF's overall opinion about IPV4 life-extension technologies.

> -d

Thanks,
Wes George, speaking as sunset4 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.

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Mon, 16 Jul 2012 09:33:46 +0000

Thanks for your comments. Please see below.

Regards,
Will

> -----Original Message-----
> From: George, Wes [mailto:[email-masked]]
> Sent: Saturday, July 14, 2012 8:36 AM
> To: Dan Wing; [email-masked]; Will Liu (Shucheng)
> Subject: RE: draft-tsou-stateless-nat44
> 
> [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). Also, there are already multiple
> competing stateless solutions. I'd rather not add another without a very good
> statement of what problem it's solving that the existing ones do not. That's
> actually the reason for question #2 - "existing technologies" also refers to
> alternate solutions to the same problem that are still in draft, not just existing
> running code.

[Will] Our solution excels other stateless ones in the following fields.
1 Security. Our solution employs discontinuous addresses. Therefore attack with a fake ip address is not an easy work. 
2 Increase the utilization rate of the port range. Users can be assigned by a proper-size port range by using the variable prefix pool.
> [WEG] excepting the typo (bypass vs pass by), the draft should say this, and in
> fact should probably say it in stronger terms - "a network using this NAT
> SHOULD deploy IPv6, so that all supporting devices and content can bypass
> the NAT and maintain end-to-end connectivity" or some similar. This is a drum
> we need to beat in every draft focused on an IPv4-only solution based on the
> way that our charter is written and IETF's overall opinion about IPV4
> life-extension technologies.
[Will] Absolutely agree. We will put it into our draft.
> 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.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Jul 2012 15:17:04 -0400

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.

> Also, there are already multiple competing stateless
> solutions. I'd rather not add another without a very good statement
> of what problem it's solving that the existing ones do not. That's
> actually the reason for question #2 - "existing technologies" also
> refers to alternate solutions to the same problem that are still in
> draft, not just existing running code.

See my response to Dan Wing for two advantages of SLNAT44 over MAP.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "George, Wes" <[email-masked]>
Date: Tue, 17 Jul 2012 11:49:22 -0400

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Monday, July 16, 2012 3:17 PM
> To: [email-masked]
> Subject: Re: [sunset4] draft-tsou-stateless-nat44
>
[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

---

From: "George, Wes" <[email-masked]>
Date: Tue, 17 Jul 2012 12:45:45 -0400

Also, there are already
> multiple
> refers to
> 1 Security. Our solution employs discontinuous addresses. Therefore
> attack with a fake ip address is not an easy work.
> 2 Increase the utilization rate of the port range. Users can be assigned
> by a proper-size port range by using the variable prefix pool.
> >
> > >
[WEG] Is there a reason that these improvements couldn't be incorporated into the other stateless solutions to optimize them (vs being their own separate implementation)?
I ask partially out of ignorance - I honestly don't know based on the current draft and subsequent explanations if there is a technical reason why we need a separate implementation instead of optimizing the existing one(s). But I also ask to further illustrate my point about existing technologies and justification: IETF has far too many drafts out there that could be summarized as: "this is like solution X, but it does this one thing differently, so it's better" or "solution X solves every use case but this one, so we've come up with a different solution that solves for this one corner case" and "no, it's just different enough that we couldn't possibly consider integrating the ideas." Then the two (or 3, or 4, or 5! ) solutions compete for the same resources within the WG, and we end up with impasses like we have in Softwire [1, 2] or RRG [3], where neither group of authors is willing to compromise and the group can't seem to get to consensus to pick a "winner". The result is that we either have multiple competing solutions, or progress stalls, or likely both. Given that this solution exists in the same space as the example I cited, I'm justifiably concerned.
Speaking personally, I like the concept of this working without specific CPE support, but as a chair, I'm not satisfied with this justification so far.

References:
[1] http://www.ietf.org/mail-archive/web/softwires/current/msg03734.html
[2] http://www.ietf.org/mail-archive/web/softwires/current/msg04221.html
[3] RFC6115

Thanks,
Wes George