Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 26 Mar 2009 16:46:37 -0400

That's an interesting use case, with definite application, but I wonder if it's really compelling in the case of the simple CPE Router. 

When CPE Routers are cascaded, the cascaded router is generally directly connected to the upstream router, so that there would be no added efficiencies from this. 

Also, service providers that I talk to are quite adamant about not wanting to see RAs coming at them from the WAN interfaces of CPE Routers. I could easily envision some SPs disabling connections where they see RAs. So CPE Routers that did this could potentially create a very bad user experience, if there were Terms and Conditions (that the customer agreed to but didn't read or necessarily understand) that said it was forbidden for them to have their router send RAs. 

I would rather if sending RAs out a WAN interface were considered a function for medium/high end business or enterprise routers, but not CPE routers. I think you will see CPE routers supplied by service providers will not do RA (or any other route advertisement) to the WAN. 
Barbara

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Mikael Abrahamsson <[email-masked]>
Cc: IPv6 Operations <[email-masked]>
Sent: Thu Mar 26 15:36:16 2009
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

On Thu, 26 Mar 2009, Mikael Abrahamsson wrote:

> This sound like a huge security problem, how are those implications handled? 
> Wouldn't the L2 device in the CO need to be able to inspect all these 
> messages and drop ones which are not assigned to that specific customer by 
> the ISP?

Perhaps you're assuming that multiple customers are sharing the same 
subnet?  In the case where customers do NOT share subnets, I fail to see 
how this adds a security problem that didn't already exist before.  In 
IPv4, if a DSL provider gives a customer a /28 instead of /30 for the WAN 
link, that customer could easily hang multiple CPE routers off of their 
WAN-side ethernet switch now and they could talk to each other.  Some of 
our customers use their WAN subnet as a DMZ and their routers are 
firewalls.  But the communication on the WAN subnet between customer 
devices stays on the local ethernet switch and shouldn't traverse the DSL 
loop.  I don't think we should cripple that capability for IPv6.

Antonio Querubin
whois:  AQ7-ARIN

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 26 Mar 2009 16:57:05 -0400

Agree, whole-heartedly!!!   We recommend CMTS service providers block
upstream RA's.
 
- Wes

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stark, Barbara
Sent: Thursday, March 26, 2009 4:47 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

That's an interesting use case, with definite application, but I wonder
if it's really compelling in the case of the simple CPE Router.

When CPE Routers are cascaded, the cascaded router is generally directly
connected to the upstream router, so that there would be no added
efficiencies from this.

Also, service providers that I talk to are quite adamant about not
wanting to see RAs coming at them from the WAN interfaces of CPE
Routers. I could easily envision some SPs disabling connections where
they see RAs. So CPE Routers that did this could potentially create a
very bad user experience, if there were Terms and Conditions (that the
customer agreed to but didn't read or necessarily understand) that said
it was forbidden for them to have their router send RAs.

I would rather if sending RAs out a WAN interface were considered a
function for medium/high end business or enterprise routers, but not CPE
routers. I think you will see CPE routers supplied by service providers
will not do RA (or any other route advertisement) to the WAN.
Barbara

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 27 Mar 2009 11:02:09 -1000 (HST)

> connected to the upstream router, so that there would be no added 

I don't think it's that uncommon.  I've seen households, small businesses, 
churches, etc that have multiple routers/switches/WAP devices scattered 
throughout the home or their buildings/offices.  While these types of 
deployments do not represent a very large percentage of how these devices 
are being used, I think we'll see more and more of these devices being 
cascaded together just for the addition of ports or access points.  The 
cost difference between a switch-only device vs a router is so minimal 
that many consumers opt for the latter even though all they really need is 
another switch in most cases.  Few of these entities have IT staff to 
advise them otherwise, nevermind efficiency.  Last time I browsed the 
network section of a computer store, I saw as many wireless devices with 
built-in routers vs just standalone WAPs/switches.  Same for the 
firewall/NAT devices.

Changing the topic slightly, it seems to me that one of the big challenges 
for the CPER is determining how the prefix sub-delegation behaviour should 
be when you do have cascaded devices.  Current IPv4 devices just avoid the 
issue by doing NAT upon NAT.  If IPv6 frees users from limits on addresses 
and subnets then the CPER behaviour should be designed to automatically 
handle the partitioning of the SP-delegated /56 or /48 among 2 or more 
downstream CPERs.  Should we try to spell out a recommended behaviour in 
more detail or are we gonna leave that up to vendor implementation?

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Mar 2009 17:24:03 -0400

>more detail or are we gonna leave that up to vendor implementation?

Please see emails in the v6ops mailer that transpired were very early
that discussed this issue.  We close the issue and recommended using
DHCPv6 server in the CPER and not use NAT like IPV4.  Please read the
cascaded router section 6 of our draft and we have recommended
sub-delegation.  Of, course the deployment must also support DHCPv6 PD.
It is intended that the sub-delegation is automatic in the CPER but we
don't plan to spell in out - it's left to vendor implementation.  

Hemant

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 30 Mar 2009 09:37:32 -0400

A cable modem can have an embedded CPE Router - known as an eRouter in
CableLabs parlance.  If the user desires wireless (802.11) connectivity
in their home, they may also buy a Wireless Access Point, which also is
typically a CPE router, and connect the two together.   This is a very
simple, and common, expected deployment (millions of people may have
this in the future), which requires cascading of CPE Routers.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Antonio Querubin
Sent: Friday, March 27, 2009 5:02 PM
To: Stark, Barbara
Cc: [email-masked]; [email-masked]
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

On Thu, 26 Mar 2009, Stark, Barbara wrote:

> That's an interesting use case, with definite application, but I 
> wonder if it's really compelling in the case of the simple CPE Router.
>
> When CPE Routers are cascaded, the cascaded router is generally 
> directly connected to the upstream router, so that there would be no 
> added efficiencies from this.

I don't think it's that uncommon.  I've seen households, small
businesses, churches, etc that have multiple routers/switches/WAP
devices scattered throughout the home or their buildings/offices.  While
these types of deployments do not represent a very large percentage of
how these devices are being used, I think we'll see more and more of
these devices being cascaded together just for the addition of ports or
access points.  The cost difference between a switch-only device vs a
router is so minimal that many consumers opt for the latter even though
all they really need is another switch in most cases.  Few of these
entities have IT staff to advise them otherwise, nevermind efficiency.
Last time I browsed the network section of a computer store, I saw as
many wireless devices with built-in routers vs just standalone
WAPs/switches.  Same for the firewall/NAT devices.

Changing the topic slightly, it seems to me that one of the big
challenges for the CPER is determining how the prefix sub-delegation
behaviour should be when you do have cascaded devices.  Current IPv4
devices just avoid the issue by doing NAT upon NAT.  If IPv6 frees users
from limits on addresses and subnets then the CPER behaviour should be
designed to automatically handle the partitioning of the SP-delegated
/56 or /48 among 2 or more downstream CPERs.  Should we try to spell out
a recommended behaviour in more detail or are we gonna leave that up to
vendor implementation?

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 30 Mar 2009 13:48:42 -0400

BTW, I expect even DSL folks will have an embedded CPE Router inside a
DSL modem.  Of course, both cable and DSL deployments can also go with
an external CPE Rtr that is standalone and not combined in one device
for both modem and router.  I would like folks to note that our draft
doesn't care.  We have defined a router specification that can be
embedded in a broadband modem or be used to build a standalone CPE
Router.  We have made such facts clear in our document.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wes Beebee (wbeebee)
Sent: Monday, March 30, 2009 9:38 AM
To: Antonio Querubin; Stark, Barbara
Cc: [email-masked]; [email-masked]
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

- Wes