Subject: Re: new version of the CPE Rtr draft is ready for review

From: Mohacsi Janos <[email-masked]>
Date: Fri, 5 Dec 2008 18:48:53 +0100 (CET)

Dear All,
 	See my comments below:

As a general comment, in my opinion there is lot of overlap with existing 
standards:

e.g. 
section 8.8 QoS
section 7 IPv6 Data Forwarding

I think the operational model can be further simplified with ND proxy 
operations (RFC ????) with pure SLAAC.

In the ND proxy operation the IPv6 allocation and operation much more 
simplified:

    [PE device]
         |
/-------+---------\
| Broadband       |
| network         |
\--------+--------/
         |
        WAN
   [CPE device]
    |  |  |  |
    LAN     WLAN

In this model PE device is issuing RA, and CPE router is receiving on WAN 
interface and proxy towards LAN and WLAN interfaces.

Advantages:
- No need to operate DHCP relay/client/server on CPE router
- No need to operate DHCP server/relay on PE device
-

Disadvantages:
- Only one /64 could be allocated to end users - no multiple subnet possible
- The users LAN/WLAN interface "Virtually connected" to PE devices - PE 
device should be protected as it would be directly to PE interface e.g. 
MAC table
- CPE router might not be capable of filtering at packet level - ND proxy 
is very similar to bridging

Further comments about the text:
Section 2:
WLAN interface - Do we have to consider ad-hoc nodes - if one uses access 
points then it is not an ad-hoc wireless network

Section 3:

IPv6 multicast - In my opinion this term is ambiguous - It would be more 
appropriate to call it "IPv6 multicast behaviour".

Section 3.1:

The numbered element 6 has to be similar to previous 5. e.g:
enable transition if DHCPv6 fails

I would also add ND proxy enable.

Section 5.3.2:
I don't see the strong host model to be defined anywhere in the document

Section 5.6.1:

The after "IPV6CP negotiates...." until the end of the section is clearly 
leftover from the previous section. - Should be removed.

Section 5.7:

"If the CPE Router needs to
    support a stateful DHCPv6 server, then more details will be added to
    this section specifying the minimal functionality that the stateful
    DHCPv6 server needs to support.
" should be rephrased:
e.g.:
Stateful DHCPv6 server support in CPE router is out of scope in this document.

Section 7:

The data forwarding might be extended in case of ND proxy - since WAN and 
LAN/WLAN treated as single SLAAC domain.

"The routing table is
    filled by directly connected, static, and routing protocol routes.
"
should be something similar to:

"The routing table is
    filled by directly connected, static, DHCP delegated prefixes and 
routing protocol routes. "

"
  Proxy Neighbor Advertisements as described in Section 7.2.8 of
    [RFC4861] are not applicable to the CPE Router.
"

I disagree in case of ND Proxy is an accepted operation.

"As per [RFC2460], the CPE Router decrements
    the Hop Limit by 1 for any packet it forwards. 
"

This sentence has to be removed - standard behaviour - no need further 
clarification.

The section should refer to RFC 4980 - ICMPv6 filtering recommmendations - 
or should be refered in draft-ietf-v6ops-cpe-simple-security-03

Section 7.2:

I would add:
"CPE may implement full MLD multicast processing."

Section 8.1:

"Routers which may encounter a packet too large to be
    forwarded from source to destination may drop the packet and send an
    ICMPv6 Packet Too Big message to the source."

I would write the following

"
Routers which may encounter a packet too large to be forwarded from source 
to destination may drop the packet and should generate an ICMPv6 Packet 
Too Big message towards the source."

Section 8.3.1:

I think stateful or stateless packet filtering is implies some default 
behaviour:

- stateless packet filtering useful only if the default behaviour is allow 
all - selectively disable unwanted traffic
- if the default behaviour is deny all incoming packet then stateful 
filtering is a must - outgoing packet should open the firewall to the 
answers - or maintaining firewall will be a nightmare

  Section 8.5:
"... the 6to4 tunneling protocol [RFC3056] MAY be enabled automatically..."

In may opinion the following option should be presented to the end user:
- No Ipv6
- IPv6 (trying getting IPv6 on WAN interface then fall back to 6to4)
- NDproxy

I would put the 2nd paragraph into a subsection 8.5.1: "Generating IPv6 
address on WAN interfaces"

Section 8.7:

>From the text "The CPE Router may also include DNS64..."
Either put into a different subsection or into a separate draft.

Section 8.8:

not necessary - does not give anything to the draft

Section 9:

Make it more precise:

"... WAN address assigned through DHCPv4 or manually configured ..."

Should be changed to:
"... WAN address assigned through DHCPv4, through PPP or manually configured..."

" A stateful firewall can enhance security by examining
    the state of each connection and only allow traffic which conforms to
    an expected packet flow."

I don't see why is this necessary here....

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Thu, 30 Oct 2008, Hemant Singh (shemant) wrote:

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-03.txt
>  
> Thanks.
>  
> Hemant & Wes
> 
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 8 Dec 2008 08:44:11 +0100

Hi,

> - Only one /64 could be allocated to end users - no multiple subnet possible

I think this is a serious-enough disadvantage that we would not want to
use ND proxy.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 8 Dec 2008 10:57:25 +0100 (CET)

> I think this is a serious-enough disadvantage that we would not want to

I think NDproxy is one option - option for clueless users how just connect 
their devices directly on the CPE wired/or wireless and not configuring 
any VLANs or subnets.

I think more than95% percent of the home users belongs to this category. 
More sophisticated methods (DHCPv6 with prefix delegation) could be 
offered to the rest of the users...

I think ND proxy could be used for mass IPv6 broadband deployment:
- no configuration required from end users on their router box if NDproxy 
is supported and switched on by default.

Best Regards,
 		Janos Mohacsi

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 8 Dec 2008 11:48:19 +0100

Janos,

Using SLAAC/ND proxy on the uplink can give some security implication
for sure when N:1 broadband architectures are used, so I think it is
better to use DHCP/DHCP PD to overcome these. service providers are used
to DHCP in broadband environments.

My 2 cents.

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mohacsi Janos
Sent: maandag 8 december 2008 10:57
To: Gert Doering
Cc: Hemant Singh (shemant); IPv6 Operations
Subject: Re: new version of the CPE Rtr draft is ready for review

On Mon, 8 Dec 2008, Gert Doering wrote:

> I think this is a serious-enough disadvantage that we would not want 
> to use ND proxy.

I think NDproxy is one option - option for clueless users how just
connect their devices directly on the CPE wired/or wireless and not
configuring any VLANs or subnets.

I think ND proxy could be used for mass IPv6 broadband deployment:
- no configuration required from end users on their router box if
NDproxy is supported and switched on by default.

Best Regards,
 		Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 8 Dec 2008 12:07:19 +0100 (CET)

> to DHCP in broadband environments.

Yes I know. This can be a problem for cable operators. Therefore I propose 
this one only as an option. In my view NDproxy can be applied in:

Broadband DSL Networks 
- PPP Terminated Aggregation (PTA) Model
- L2TPv2 Access Aggregation (LAA) Model

Broadband Ethernet Networks
- PPP Terminated Aggregation (PTA) Model
- L2TPv2 Access Aggregation (LAA) Model

and probably:
Wireless LAN
- PPP-Based Model

with RFC 4779 terminology.

Regards,
 		Janos Mohacsi

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2008 11:26:24 +1300

> NDproxy is supported and switched on by default.

The trouble with this argument is: what happens twenty years from
now, when multiple subnets in the home or small office become common,
but the industry-standard $50 CPE uses this model and cannot be
configured to deliver a shorter prefix than /64? That would be just
like the problem we have today where all CPEs are legacy devices
as far as IPv6 is concerned.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2008 13:01:58 +1300

On 2008-12-09 12:18, John Curran wrote:
> On Dec 8, 2008, at 5:26 PM, Brian E Carpenter wrote:
>>
>> configured to deliver a shorter prefix than /64?
> 
> Brian -
> 
> By "when the industry-standard $50 CPE uses this model and cannot be
> configured to deliver a shorter prefix" do you mean:
> 
> 1) is shipped only with NDproxy and without DHCPv6 support, and is
>    forever broken
> 
> or simply
> 
> 2) has NDproxy turned on by default, and therefore assumes just one
>    /64 in use (until/unless the user switches it to DHCPv6)

Either would be a problem, but 1) would of course be a worse
problem IMNSHO. However, even getting Joe User to change a default
setting as in 2) would seem likely to generate a lot of help
desk traffic related to obsolete products.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Tue, 9 Dec 2008 09:47:40 -0800

On Dec 8, 2008, at 01:57, Mohacsi Janos wrote:
>
> I think more than95% percent of the home users belongs to this  
> category. More sophisticated methods (DHCPv6 with prefix delegation)  
> could be offered to the rest of the users...

I disagree.  I foresee a time in the very near future when most  
residential users will need at least two subnets, one for their own  
use and one for the use of their guests with mobile devices.  I do not  
believe residential subscribers will accept systems that require  
giving their temporary guests full access to their private home  
networks even on a temporary basis.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 9 Dec 2008 15:26:30 -0500

On Tue, Dec 09, 2008 at 09:47:40AM -0800, james woodyatt wrote:
> residential users will need at least two subnets, one for their own use 
> and one for the use of their guests with mobile devices.  I do not  
> believe residential subscribers will accept systems that require giving 
> their temporary guests full access to their private home networks even on 
> a temporary basis.

You think residential subscribers even know the difference or what 
"full access" or "subnet" means?  You have more faith in users than I 
do.

---

From: james woodyatt <[email-masked]>
Date: Tue, 9 Dec 2008 13:46:17 -0800

On Dec 9, 2008, at 12:26, Chuck Anderson wrote:
>> use
>> giving
> "full access" or "subnet" means?  You have more faith in users than  
> I do.

No, I don't think they should have to know the technical details  
necessary to give them what they want, but I do think A) that's what  
they want, and B) the right way to give it to them is to have more  
than one subnet.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 9 Dec 2008 13:51:51 -0800

> "full access" or "subnet" means?  You have more faith in users than I

There lies the rub. The subnet is not a very good match to the notion of home network. For a user, the "home network" is "the machines in my home", which may or may not be actually connected to the same subnet. For example, my cell phone may or may not be connected to the wi-fi home network, yet I expect it to get music files from my home server. Conversely, if I live in an apartment building, there may well be computers that are connected to the same subnet, yet should not be allowed to mess with my home machines.

Bottom line, we should stop relying to the wiring topology for security.

-- Christian Huitema

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 10 Dec 2008 15:18:28 +0100 (CET)

On Tue, 9 Dec 2008, james woodyatt wrote:

>> More sophisticated methods (DHCPv6 with prefix delegation) could be offered 
>> to the rest of the users...
>
>
> I disagree.  I foresee a time in the very near future when most residential 
> users will need at least two subnets, one for their own use and one for the 
> use of their guests with mobile devices.  I do not believe residential 
> subscribers will accept systems that require giving their temporary guests 
> full access to their private home networks even on a temporary basis.

Then 90% users will buy a new home router.... The current devices are 
rarely support more than one subnet with the shipped firmware....

Regards,
 	Janos Mohacsi

---

From: james woodyatt <[email-masked]>
Date: Wed, 10 Dec 2008 09:25:35 -0800

On Dec 10, 2008, at 06:18, Mohacsi Janos wrote:
>> use and one for the use of their guests with mobile devices.  I do  
>> not believe residential subscribers will accept systems that  
>> require giving their temporary guests full access to their private  
>> home networks even on a temporary basis.
>
> Then 90% users will buy a new home router.... The current devices  
> are rarely support more than one subnet with the shipped firmware....

Yes, but the firmware in current devices can be upgraded, but it will  
only help if the subscriber prefixes are shorter than 64 bits.  This  
is why I don't see the ND proxy service model that started this  
discussion as a very reasonable one, and I don't think it should be  
recommended as Best Current Practice.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 10 Dec 2008 12:34:51 -0500

I see the ND Proxy model as having a very limited applicability:

The service provider offers a /64 subnet and the home router has two
different physical media that can't be bridged (eg. Firewire and
Ethernet) - and you need connectivity between the incompatible media
types.  Then, it's appropriate to use ND proxy.  Note, however that ND
proxy cannot be used with a subnet bigger than a /64.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of james woodyatt
Sent: Wednesday, December 10, 2008 12:26 PM
To: IPv6 Operations
Subject: Re: new version of the CPE Rtr draft is ready for review

On Dec 10, 2008, at 06:18, Mohacsi Janos wrote:
>> not believe residential subscribers will accept systems that require 

Yes, but the firmware in current devices can be upgraded, but it will
only help if the subscriber prefixes are shorter than 64 bits.  This is
why I don't see the ND proxy service model that started this discussion
as a very reasonable one, and I don't think it should be recommended as
Best Current Practice.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 10 Dec 2008 12:58:56 -0500

Hopefully this will reply to all folks who asked about ND Proxy on this
mailer since Teemu first asked about it for a cellular device which will
have disparate MAC layer between the cellular network and the bluetooth
network.  I don't think we authors have to reply any more on the ND
Proxy thread and also consider this discussion on the ND Proxy closed
for the draft.  We can then move on to replying to some other comments
folks have made.  

We will add a short ND Proxy sub-section to section 7 that basically
says what Wes has said below is a very tight language.

Stay tuned.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wes Beebee (wbeebee)
Sent: Wednesday, December 10, 2008 12:35 PM
To: james woodyatt; IPv6 Operations
Subject: RE: new version of the CPE Rtr draft is ready for review

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 12 Dec 2008 14:17:29 -0500

Janos,

Thanks very much for the detailed review.  Sorry for the delayed reply.
Please see in line below between <hs> and </hs>.  I have removed some
text from your original email to make my email reply a little shorter. 

-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: Friday, December 05, 2008 12:49 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: new version of the CPE Rtr draft is ready for review

Dear All,
 	See my comments below:

As a general comment, in my opinion there is lot of overlap with
existing
standards:

e.g. 
section 8.8 QoS

<hs>Listen to audio sessions of IETF 72 where I said, the device is not
merely a router.  The device may have a bridge inside it, have switched
and routed ports, so the data forwarding for all such devices together
has to be clearly defined.  There may be overlap, but we authors are in
the business of getting such a device build ASAP and the document serves
to facilitate vendors.  See the new Abstract that mentions such facts.
As for the Qos section, it's for completeness for what features are
suggested to be in the device.  
</hs>

<hs>
See Wes' or my reply about ND Proxy to the mailer.
</hs>

<hs>
Thanks, we have accepted your comment.
</hs>

Section 3.1:

<hs>
Perfect editorial comment.  Will do.
</hs>

Section 5.3.2:

<hs>
RFC 1122 is referenced in the document.  This RFC discusses both strong
and weak host models.  If you are not familiar with such models and want
a quick overview rather than sifting thru RFC 1122, please see
http://en.wikipedia.org/wiki/Host_model
</hs>

Section 5.6.1:

The after "IPV6CP negotiates...." until the end of the section is
clearly 
leftover from the previous section. - Should be removed.

<hs>
It is intentional. Some common behavior is repeated in different
protocol sections.  Actually, one reviewer in David Miles wanted the
same text to be included in section 5.6.1 and that is why we complied.
Maybe in the new version we will make one sub-section to describe the
common text and then just point to this section in multiple protocol or
model sections.
</hs>

Section 5.7:

Stateful DHCPv6 server support in CPE router is out of scope in this
document.

<hs>
Good point.  We may just add a reference for RFC 3315 or if the
community decided they want a brief description of the server, we may
consider that input.
</hs>

Section 7:

The data forwarding might be extended in case of ND proxy - since WAN
and 
LAN/WLAN treated as single SLAAC domain.

<hs>
When we add the new ND Proxy sub-section, we will update the Data
Forwarding section too. 
</hs>

"The routing table is

"The routing table is

<hs>
Good suggestion.  We will see what to incorporate in this sentence for
PD's.
</hs>

"

<hs>
You are correct.  When I added the new ND Proxy sub-section to a new
private version of the draft, this statement has been removed from the
document.
</hs>

<hs>
Yes, we will consider removing the statement.
</hs>

The section should refer to RFC 4980 - ICMPv6 filtering recommmendations
- 
or should be refered in draft-ietf-v6ops-cpe-simple-security-03

<hs>
OK, good suggestion - will do.
</hs>

Section 7.2:

I would add:

<hs>
If MLD Proxy works to receive mcast data from the SP to the home, why do
we want to even add a "MAY support full MLD mcast processing"?  We do
point to full mcast functionality in the last paragraph of this section
for the case if the home wants to send mcast data out to the Internet.
The text of the section is fine as is unless you can show any case we
missed that would require full MLD mcast processing.
</hs>

Section 8.1:

"
Routers which may encounter a packet too large to be forwarded from
source 
to destination may drop the packet and should generate an ICMPv6 Packet 
Too Big message towards the source."

<hs>
Disagree with your recommendation that says "should generate an ICMPv6
Packet" rather than use our text that is essentially saying the error
message must be sent.  Our text is correct because RFC4443, in section
3.2 says the following:
[A Packet Too Big MUST be sent by a router in response to a packet
 that it cannot forward because the packet is larger than the MTU of
 the outgoing link.]
</hs>

Section 8.3.1:

- stateless packet filtering useful only if the default behaviour is
allow 

<hs>
Let me check the cpe-simple-security draft (been a while since I read
that draft and I don't remember details from it right now) and see if
any default behavior for filters is mentioned in that document.
Otherwise, we may expand our section for any defaults.
</hs>

  Section 8.5:
"... the 6to4 tunneling protocol [RFC3056] MAY be enabled
automatically..."

<hs>
We already mention item two in your end user choices in the document.
How does the CPE Router know there is "No Ipv6", so is there really a
need for the first choice?  Then I don't understand what does ND Proxy
have anything to do with 6to4?
</hs>

<hs>
You suggestion is worth thinking about.  We'll mull over it.
</hs>

<hs>
Whatever DNS functionality including DNS64 the CPE router has to deal
with will be outlined in our draft.  
</hs>

Section 9:

Make it more precise:

Should be changed to:
"... WAN address assigned through DHCPv4, through PPP or manually
configured..."

<hs>
Agreed - will do.
</hs>

" A stateful firewall can enhance security by examining
    the state of each connection and only allow traffic which conforms
to
    an expected packet flow."

<hs>
As this section says, we describe common practice out there for IPv4 CPE
Rtr.  The text above is in line with that.
</hs>

Kind Regards.

Hemant

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Dec 2008 21:41:18 +1030

Hi,

On Mon, 8 Dec 2008 10:57:25 +0100 (CET)

> > On Fri, Dec 05, 2008 at 06:48:53PM +0100, Mohacsi Janos wrote:
<snip>

> is supported and switched on by default.

Existing IPv4 ADSL routers (at least the ones I see here in .au) come
with routing enabled, a single subnet behind the device (which may be
a bridged wired/wireless/USB segment), and a DHCP server (and NAT of
course). Customers don't seem to have any trouble with that setup,
because the CPE comes configured to operate that way. The only
interaction a customer might have is to type their assigned PPPoE/A
username/password in, and that is commonly automated via a setup CD,
rather than via the Web interface on the device.

I can't really see any reasons why residential IPv6 CPE needs to be
much different.

Regards,
Mark.