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

["Will Liu (Shucheng)" <[e-mail]>]

Thanks for your comments. Please see below.

Regards,
Will


> -----Original Message-----
> From: George, Wes [mailto:[e-mail]]
> Sent: Saturday, July 14, 2012 8:36 AM
> To: Dan Wing; [e-mail]; Will Liu (Shucheng)
> Subject: RE: draft-tsou-stateless-nat44
> 
> > From: Dan Wing [mailto:[e-mail]]
> > Sent: Wednesday, July 11, 2012 12:44 PM
> > To: George, Wes; [e-mail]; '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.

[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.
> 
> >
> > > 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.
[Will] Absolutely agree. We will put it into our draft.
> 
> >
> > -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.