Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Lee Howard [mailto:[e-mail]]
> Sent: Wednesday, September 07, 2011 11:06 AM
> To: 'Dan Wing'; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Int-area] IPv4 address sharing abuse [was RE: draft-
> boucadair-intarea-nat-reveal-analysis]
> 
> Is it true that the stacks/applications on the devices you name could
> be updated as described, but could not be updated to support IPv6?

The host stacks wouldn't be updated.  

The address-sharing device (NAT, A+P router, etc.) would add the
additional data.  

> That section of rfc6269 says blacklisting and penalty boxes won't work.
> For the solutions offered, the effort of draining the cesspool may be
> greater than living with the stink (or moving to the new house with all
> the extra bits).
> 
> The draft nicely describes the solution space, though.

-d

> Lee
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Dan
> > Wing
> > Sent: Tuesday, September 06, 2011 7:37 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [Int-area] IPv4 address sharing abuse [was RE:
> draft-boucadair-intarea-nat-reveal-
> > analysis]
> >
> > Dearest Internet Area,
> >
> > The INTAREA document RFC6269 discussed the harm of IPv4 abuse in
> > http://tools.ietf.org/html/rfc6269#section-13.1 and we're trying to
> see if
> > there is interest in solving the problem for IPv4 users -- some of
> whom
> > cannot or will not upgrade to IPv6 (IPv4-only television, Roku
> streaming
> > player, Grandma's Windows 95 box, etc.).  If this isn't solved, IPv4
> will
> > become a cesspool or very expensive to continue to operate for
> content
> > providers (who will have to terminate TCP and TLS sessions for
> abusers and
> > legitimate users, alike).
> >
> > -d
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> On
> > > Behalf Of Dan Wing
> > > Sent: Friday, July 22, 2011 2:10 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: [Int-area] draft-boucadair-intarea-nat-reveal-analysis
> > >
> > > I realize INTAREA is not meeting at IETF81, but we would like to
> bring
> > > attention to the informational document
> > > http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-
> analysis,
> > > abstract:
> > >   "This document analyzes a set of solution candidates which have
> been
> > >    proposed to mitigate some of the issues encountered when address
> > >    sharing is used.  In particular, this document focuses on means
> to
> > >    reveal a host identifier when a Carrier Grade NAT (CGN) is
> involved
> > >    in the path.  This host identifier must be unique to each host
> under
> > >    the same shared IP address.
> > >
> > >    The ultimate goal is to assess the viability of proposed
> solutions
> > >    and hopefully to make a recommendation on the more suitable
> > >    solution(s)."
> > >
> > > This document seems to belong in INTAREA, considering the various
> > > solutions
> > > to the abuse problem described in that document is due to IPv4
> address
> > > sharing, and INTAREA has already taken on documents related to IPv4
> > > address sharing:
> > >   draft-ietf-intarea-shared-addressing-issues       (RFC6269)
> > >   draft-ietf-intarea-server-logging-recommendations (RFC6302)
> > >
> > >
> > > Based on that analysis document, the most preferred solution is
> > > draft-wing-nat-reveal-option (standards track).  I expect we will
> > > pursue draft-wing-nat-reveal-option in BEHAVE or perhaps TSVWG.
> > >
> > > -d
> > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/int-area
> >
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area