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

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

> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]]
> Sent: Friday, October 14, 2011 5:07 PM
> To: Dan Wing
> Cc: 'Tassos Chatzithomaoglou'; [e-mail]; draft-ietf-v6ops-
> [e-mail]
> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> 
> 
> On Oct 13, 2011, at 6:23 PM, Dan Wing wrote:
> 
> >> -----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.
> 
> I have no argument that PCP is a reasonable solution if you say it is.
> I haven't looked at it. But to my mind, a combination of a firewall
> protecting the network from traffic that it has no application to
> receive, and a protocol that an application can use to say "please
> permit {source/destination address/port, protocol} traffic in your ACL
> until <time> or for <time units>" makes a lot of sense. Just tell me
> that the protocol sends its requests to a multicast group, so that if
> there is no firewall it doesn't overload the network and if there is
> the firewall will have joined said multicast group.

Right now, it just goes to the default router.  There is a planned
DHCP & DHCPv6 option to specify an alternate address 
(draft-bpw-pcp-dhcp), which could certainly be a multicast address.

> That said, they tell me that in an IPv6 network there will be no need
> for this on the WAN side, as there will be no CGN. This draft is about
> the WAN side, and anything on the LAN side is in homenet...

IPv6 networks are pretty likely to have a NAT64 (NAT64 is a "CGN64", 
really), until all interesting servers running IPv4-only today are
dual stack.  PCP would be running between that RFC6204bis CPE 
and the network's NAT64 device, like this:

  [IPv6-only host]---[RFC6204bis CPE]------[NAT64]--{IPv4 Internet}
                                     ^^^^^^
                                       PCP

-d


> > -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
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops