Perry Lorier's comments on CPE drafts

Forwarded with permission.

    Brian

-------- Original Message --------
Subject: Re: [Ipv6-techsig] [spam?] Various IPv6 bits and bobs
Date: Sun, 01 Nov 2009 13:52:29 +1300
From: Perry Lorier <perry@...>
Reply-To: ipv6-techsig@...
To: ipv6-techsig@...
References: <8df701f90910281853m5a0e993ft4438a9cc2d5bd9f4@...>	<4AE8FFAD.4060601@...>

Brian E Carpenter wrote:
> Dave,
>
> Are the vendors aware of the developing specs for CPE functionality
> and security, or are they making it up as they go along?
>
> draft-ietf-v6ops-ipv6-cpe-router
>   

WPD-3: If the delegated prefix is an aggregate route of multiple,
more-specific routes the IPv6 CE router MUST discard packets  that match
the aggregate route, but not any of the more- specific routes.

Not send ICMP6 Destination network unreachable?  I guess they're trying
to stop people from mapping which segments are in use?  But if a network
is in use, but the host isn't there then it's going to reply with ICMP6
Destionation host unreachable when neighbour discovery times out?

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

Hi,

Internet-Drafts@... wrote
  in <20091026214501.DF8C23A6950@...>:

In> A New Internet-Draft is available from the on-line Internet-Drafts directories.
In> This draft is a work item of the IPv6 Operations Working Group of the IETF.
In>
In>
In> 	Title           : Requirements for IPv6 Customer Edge Routers
In> 	Author(s)       : H. Singh, et al.
In> 	Filename        : draft-ietf-v6ops-ipv6-cpe-router-02.txt
In> 	Pages           : 14
In> 	Date            : 2009-10-26

(Section 4.1)
 | When the router is attached to the WAN interface link it must act as
 | an IPv6 host for the purposes of IPv6 interface initialisation, ND
 | Router Discovery, Prefix Discovery and interface address assignment
 | ([RFC4861]/[RFC4862]).  The router acts as a requesting router for
 | the purposes of DHCP prefix delegation ([RFC3633]).

 I think this description is unclear whether the router must "act as
 an IPv6 host" on WAN side even after interface initialization or not.
 More specifically, 1) we should set or not the R-bit in Neighbor
 Advertisement messages on WAN side, and 2) the WAN interface can
 respond to Router Solicitation messages or not.

 IMO when the CE router is working as an IPv6 router (IsRouter flag in
 RFC4861 is enabled) after the provisioning, the IPv6 router behavior

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

Hiroki,

> (Section 4.1)
>  | When the router is attached to the WAN interface link it must act as
>  | an IPv6 host for the purposes of IPv6 interface initialisation, ND
>  | Router Discovery, Prefix Discovery and interface address assignment
>  | ([RFC4861]/[RFC4862]).  The router acts as a requesting router for
>  | the purposes of DHCP prefix delegation ([RFC3633]).
>
>  I think this description is unclear whether the router must "act as
>  an IPv6 host" on WAN side even after interface initialization or not.
>  More specifically, 1) we should set or not the R-bit in Neighbor
>  Advertisement messages on WAN side, and 2) the WAN interface can
>  respond to Router Solicitation messages or not.

for the purposes of SLAAC, router discovery etc it should always act
as a host on the WAN interface. it should not reply to RS messages nor
set the R-bit in NAs.
I'll take a stab at better text, but feel free to suggest something.

>  IMO when the CE router is working as an IPv6 router (IsRouter flag in
>  RFC4861 is enabled) after the provisioning, the IPv6 router behavior
>  of Neighbor Discovery makes sense.  If the IP forwarding is disabled
>  for some reason, acting as a host on WAN interface link would be
>  reasonable for re-initialization.

IP forwarding is enabled on the WAN interface. it is only for address
assignment that the host functions of RFC4861/4862 are used. the
interface is acting as _both_ a router and a host on the interface.

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

Ole Troan <otroan@...> wrote
  in <2bbba3c10911030123t66c2d4adi2d8f0fe83a6fbfb7@...>:

ot> Hiroki,
ot> 
ot> > (Section 4.1)
ot> >  | When the router is attached to the WAN interface link it must act as
ot> >  | an IPv6 host for the purposes of IPv6 interface initialisation, ND
ot> >  | Router Discovery, Prefix Discovery and interface address assignment
ot> >  | ([RFC4861]/[RFC4862]).  The router acts as a requesting router for
ot> >  | the purposes of DHCP prefix delegation ([RFC3633]).
ot> >
ot> >  I think this description is unclear whether the router must "act as
ot> >  an IPv6 host" on WAN side even after interface initialization or not.
ot> >  More specifically, 1) we should set or not the R-bit in Neighbor
ot> >  Advertisement messages on WAN side, and 2) the WAN interface can
ot> >  respond to Router Solicitation messages or not.
ot> 
ot> for the purposes of SLAAC, router discovery etc it should always act
ot> as a host on the WAN interface. it should not reply to RS messages nor
ot> set the R-bit in NAs.

 Thank you for the clarification.  Correct me if I am wrong, but in my
 understanding, for router discovery and SLAAC the node must
 accept/process RAs and must discard received RSes.  This means
 "acting as a host", but is there a technical reason to always set
 R-bit in NAs zero?  A CE router has a moment of transition from a
 host to a router (after provisioning, for example) and vice versa as
 viewed from the PE router, so making R-bit depend on whether IP
 forwarding is enabled or not still seems reasonable to me.

RE: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

> Thank you for the clarification.  Correct me if I am wrong, but in my
understanding, for router
> discovery and SLAAC the node must  accept/process RAs and must discard
received RSes.  This means 
> "acting as a host", but is there a technical reason to always set
R-bit in NAs zero?  A CE router
> has a moment of transition from a  host to a router (after
provisioning, for example) and vice
> versa as  viewed from the PE router, so making R-bit depend on whether
IP  forwarding is enabled
> or not still seems reasonable to me.

-----------------------------------------------------------------------
> When the router is attached to the WAN interface link it must act as 
> an IPv6 host for the purposes of Neighbor Discovery[RFC4861] and IPv6 
> Stateless Address Autoconfiguration[RFC4862].  The router acts as a
requesting router for the purposes of DHCP prefix delegation
([RFC3633]).

And, obviously, the router routes traffic out the WAN interface and does
NOT use the Conceptual Sending Algorithm of Neighbor Discovery to do so,
but rather a proper routing table.  The LAN interface acts as a router
when sending RA's, but both the WAN and LAN act as a host when the
router is being configured (e.g. with SNMP/HTTP).  The LAN port acts as
a router for the purposes of IPv6 SLAAC even though the WAN port acts as
a host.

So, as you can see, a CPE Router is both a router and a host on its WAN
interface.

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

Hiroki,

[...]

> ot> for the purposes of SLAAC, router discovery etc it should always act
> ot> as a host on the WAN interface. it should not reply to RS messages nor
> ot> set the R-bit in NAs.
>
>  Thank you for the clarification.  Correct me if I am wrong, but in my
>  understanding, for router discovery and SLAAC the node must
>  accept/process RAs and must discard received RSes.  This means
>  "acting as a host", but is there a technical reason to always set
>  R-bit in NAs zero?  A CE router has a moment of transition from a
>  host to a router (after provisioning, for example) and vice versa as
>  viewed from the PE router, so making R-bit depend on whether IP
>  forwarding is enabled or not still seems reasonable to me.

I don't think you can say that there is a transition from a host to a
router. it is performing functions of both at the same time, all the
time. e.g it will continue to process received RAs as long as the
interface is up...

>  Even if doing so the R-bit should not prevent the CE router from
>  router discovery or SLAAC.  While pretending a host by always setting
>  the R-bit zero would work certainly, to me there is no strong reason
>  to disable the functionality.

to turn the question around, why would you want to enable the flag?
for these types of links it is unlikely to be another host there, even
so I would avoid any situation where a host on the WAN link would end

Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

Hi,

A CE router often contain a bridge on the LAN side with Ethernet, Wifi interfaces attached to it.

Without MLD snooping [RFC4541] on the LAN bridge, a multicast flow will flood all segments on all interfaces.

Significant bandwidth can be wasted by flooding.

That is why I propose a L-10 requirement:

L-10: If the CE router is build with a bridge on the LAN side, it MUST
      use MLD snooping [RFC4541] to avoid flooding multicast frames on
      all segments.

Best regards,
Francois-Xavier

--- On Mon, 10/26/09, Internet-Drafts@...
<Internet-Drafts@...> wrote:

> From: Internet-Drafts@... <Internet-Drafts@...>
> Subject: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt
> To: i-d-announce@...
> Cc: v6ops@...
> Date: Monday, October 26, 2009, 5:45 PM
> A New Internet-Draft is available
> from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations Working
> Group of the IETF.
> 

RE: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-02.txt

Francois-Xavier,

Please note that this version of the CE Rtr draft (-02) which we call as
Phase I does not included any mcast behavior definition.  The SP's
working on the design team could not agree to putting mcast in the Phase
I document.  So when the Phase II gets worked on, as we have discussed
in the v6ops mailer in the past, this bridged mcast will be added as a
requirement in the document.  Do expect such text in the Phase II
document.

Note the Phase II document (after the San Francisco IETF in March 2009)
is the document below.

http://tools.ietf.org/id/draft-wbeebee-v6ops-ipv6-cpe-router-bis-01.txt

Since mcast was moved out of CE Rtr Phase I, it is included as is in the
bis doc above.  "As is" means what we agreed upon in the v6ops mailer
with you on MLDv2 snooping.  This is the text we have

If the CPE Router hardware includes a network bridge between the WAN
interface and the LAN interface(s), then the CPE Router MUST support
MLDv2 snooping as per [RFC4541].

When the design team starts work on Phase II document, this bis version
will also morph into the format being used in the
raft-ietf-v6ops-ipv6-cpe-router-02.txt.

Thanks,

Hemant

RE: Broadband Forum liaison to IETF on IPv6 security

RE: Broadband Forum liaison to IETF on IPv6 security