> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Tassos Chatzithomaoglou
> Sent: Thursday, October 13, 2011 1:51 PM
> To: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org
> 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

> As a sidenote, i WOULD like to see in this draft just a section
> referring to PCP (like 8.5 in RFC 6333), if PCP requirements are going
> to be left out from this.
> 
> 
> 
> Also, i would like to make some other comments on draft-ietf-v6ops-
> 6204bis-00.
> 
> 
> In G-2 & L-14, ICMP should be changed to ICMPv6.
> 
> 
> 
> 	   6RD-3:  If the CE router implements 6rd functionality, it MUST
> allow
> 	           the user to specify whether all IPv6 traffic goes to
> the 6rd
> 	           Border Relay, or whether other destinations within the
> same
> 	           6rd domain are routed directly to those destinations.
> 
> 
>    6RD-3:  If the CE router implements 6rd functionality, it MUST allow
>            the user to specify whether all IPv6 traffic goes to the 6rd
>            Border Relay, or whether IPv6 traffic towards other
> destinations within the same
>            6rd domain is routed directly to those destinations.
> 
> 
> 	More specifically,
> 	   Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6
> tunnel at
> 	   the IPv6 CE Router and sends it to a Service Provider Address
> Family
> 	   Translation Router (AFTR).
> 
> 
> More specifically,
>    Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
>    the IPv6 CE Router and sends it to a Service Provider Address Family
>    Transition Router (AFTR).
> 
> 
> 	   DLW-2:  If the IPv6 CE Router implements DS-Lite
> functionality, the
> 	           CE Router MUST support using a DS-Lite DHCPv6 option
> 	           [I-D.ietf-softwire-ds-lite-tunnel-option
> <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-00#ref-I-D.ietf-
> softwire-ds-lite-tunnel-option> ] to configure the
> 	           DS-Lite tunnel.  The IPv6 CE Router MAY use other
> mechanisms
> 	           to configure DS-Lite parameters.  Such mechanisms are
> outside
> 	           the scope of this document.
> 
> 
>    DLW-2:  If the IPv6 CE Router implements DS-Lite functionality, the
>            CE Router SHOULD support using a DS-Lite DHCPv6 option
>            [RFC 6334] to configure the
>            DS-Lite tunnel.  The IPv6 CE Router MAY use other mechanisms
>            to configure DS-Lite parameters.  Such mechanisms are
> outside
>            the scope of this document.
> 
> RFC 6333 says that the DS-Lite DHCPv6 option is a SHOULD.
> "7.1. Normative References" should be updated with the RFC number too
> 
> 
> 
> 	   Run the following four in parallel to provision CPE router
> 	   connectivity to the Service Provider:
> 
> 	   1.  Initiate IPv4 address acquisition.
> 
> 	   2.  Initiate IPv6 address acquisition as specified by [RFC6204
> <http://tools.ietf.org/html/rfc6204> ].
> 
> 	   3.  If 6rd is provisioned, initiate 6rd.
> 
> 	   4.  If DS-Lite is provisioned, initiate DS-Lite.
> 
> 
> I can't see how all four can run in parallel.
> 
> 
>    Run the following two in parallel to provision CPE router
>    connectivity to the Service Provider:
> 
>    1.  Initiate IPv4 address acquisition.
> 
>    2.  Initiate IPv6 address acquisition as specified in Section 4.2.
> 
>    Then,
> 
>    If IPv4 address acquisition is successful and 6rd is provisioned,
> initiate 6rd.
> 
>    If IPv6 address acquisition is successful and DS-Lite is
> provisioned, initiate DS-Lite.
> 
> 
> Lastly, i would also like to have the following under "4.5. Security
> Considerations". Unless we are leaving this functionality to the
> AFTR/BR (although i couldn't find anything relevant; PCP?).
> 
> S-3:  The IPv6 CE router MUST support the configuration of a common
> filtering behavior, regardless of the interface type that traffic is
> coming through (native or through a transition/tunneling technology).
> 
> 
> 
> --
> Tassos