Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

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

> -----Original Message-----
> From: Tassos Chatzithomaoglou [mailto:[e-mail]]
> Sent: Friday, October 14, 2011 12:43 AM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> 
> 
> Dan Wing wrote on 14/10/2011 04:23:
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf
> >> Of Tassos Chatzithomaoglou
> >> Sent: Thursday, October 13, 2011 1:51 PM
> >> To: [e-mail]; [e-mail]
> >> Subject: [v6ops] new draft: draft-ietf-v6ops-6204bis
> >>
> >>
> >> Just to add to everyone else that expressed the desire to see DS-
> Lite
> >> in this, i totally agree with them.
> >> We recently run an RFP looking for IPv6 CPEs from various vendors
> and
> >> nobody of them had a official version supporting it.
> >> We even got answers from vendors (that are very active inside IETF),
> >> that they are not planning to implement it.
> >> So having a standard RFC "pushing" them in that direction is always
> >> welcome.
> >>
> >> Regarding PCP, i would also like to have it as a basic requirement.
> But
> >> i can live with the assurance that when finished, it will be added
> >> (maybe somewhere else).
> >> Currently, we are planning to enable DS-Lite only to subscribers
> that
> >> have all port forwarding methods disabled in their CPE, so we can
> >> "bypass" a need for it.
> >> But as the number of subscribers grows, we'll surely need a way to
> make
> >> port forwarding (+other stuff) work in CGN.
> > PCP is not just about IPv4 and is not just about CGN.
> >
> > Ignore IPv4 for a moment.  Let's concentrate on IPv6.
> >
> > For IPv6, if the CPE going to comply with RFC6092 (Simple CPE
> > Security), incoming unsolicited traffic will be blocked.  If the
> > IPv6 host is hoping to run an Internet-facing server, the host and
> > and CPE will need to either:
> >    (1) implement UPnP IGD 2.0 (which supports IPv6 firewall), or
> >    (2) implement PCP (which supports IPv6 firewall), or
> >    (3) the user will have to configure exceptions manually in
> >        their CPE (e.g., using web pages).
> >
> > I think PCP is the best answer of those three, because it works
> > in all anticipated mixes of technology that may be deployed on
> > a particular network for that network's IPv6 transition,
> > including NAT64, NPTv6, NAT46, NAT44, etc.
> >
> > -d
> 
> Dan,
> 
> I had the impression that for Internet-facing servers the best (in
> terms of 100% correct
> behavior) answer was No 3; configure it manually on the CPE.
> At least this is based on my experience on IPv4 CPEs (haven't seen a
> fully working firewall on IPv6 CPEs).
> On other hand, i am more of a manual config guy (i want to know what's
> open and what's
> not), so maybe i am missing the typical subscriber's "best" answer.

The typical subscriber doesn't have any clue how to configure their
CPE, nor understand the need to do so.  Think of Joe Sixpack, Grandma,
or the actors on TV commercials as typical subscribers -- not IETFers
who are smart enough to be involved in IPv6.

> Imho seeing PCP client support in hosts and applications might take a
> while. I was hoping
> for PCP on the CPE WAN side as a first. I see it as more urgent.

It's all in what Apple/Linux/Microsoft add to their products.


> btw, quoting from draft-ietf-pcp-base-14, "Introdution":
> 
> PCP is designed to be implemented in the context
>     of both Carrier-Grade NATs (CGNs) and small NATs (e.g., residential
>     NATs).  PCP allows hosts to operate servers for a long time (e.g.,
> a
>     webcam) or a short time (e.g., while playing a game or on a phone
>     call) when behind a NAT device, including when behind a CGN
> operated
>     by their Internet service provider.
> 
> Although, IPv4/IPv6 firewalls are referenced further inside the text, i
> would like to see
> them here too.

Ok, will be mentioned in -15 up front.  Thanks.

-d


> 
> 
> --
> Tassos